http://qs321.pair.com?node_id=821563


in reply to Re^2: Top Level Module Namespace Table
in thread Top Level Module Namespace Table

Amazing how difficult it is for me to express myself precisely on this issue! I thought an example would be explicit. Sorry. Please allow me to attempt to improve.

I'm well acquainted with CPAN Search; it's a great tool. I'm not sure how much an ordinary dev will want to use Parse::CPAN::Modlist; but that's cool. Both of these are solutions to the problem of I want to download a module that does This. They are statements of what is. This is a common problem and an important one; but it's not the issue I'm attempting to address.

The table I seek is not descriptive but prescriptive. This is where the markers for deprecated namespaces come in.* This table goes no further than the top level of namespaces, perhaps some well-defined second levels (e.g., CGI::Application::). It's a statement of what should be.

Reviewing the descriptions of existing modules is indeed a way to infer prescriptions for future efforts, I admit. By the same token, one course of bricks is a guide to placing the next. Yet, if we want a wall to stand neatly, we generally use a plumb line.

I realize that I touch upon philosophical issues here.** My feeling is only that I will be more comfortable writing modules -- even modules that may never escape from my own project -- that are named in conformance with some plan.

I'm coming rapidly to the belief that no such table exists (I'd like to be wrong!) and that creating it is a worthwhile project. I wrote the original node in hopes that Monks might suggest a good way to get it started.

*

I don't personally assert that all modules currently under CLI:: should have fallen under Getopt:: or that all CLI-related modules should be created under the latter; but it's the kind of assertion that someone with more experience ought to be able to make.

I do assert that no module should be created under the Data:: namespace. I'm sure vigorous arguments can be mounted in support of it but I side with petdance that data is the world's worst identifier. All modules manipulate data.

**

Description vs Prescription is an old war in pedagogy, particularly among teachers of English grammar. At one time, prescriptive grammar was the unchallenged model, leading to textbooks insisting on awkward constructions and forbidding much common usage. The descriptive reaction reached its nadir with Ebonics.

I taught English as a Foreign Language for some time. My personal bias as an instructor is strongly descriptive; but in my own writing I try mostly to follow the ancient prescriptions. I do employ a few neologisms and nonstandard punctuation schemes. For instance, the rule is that quotes enclose trailing punctuation; I find this "intolerable".

My intention here is to balance, not overturn, the excellent descriptions provided by CPAN authors of existing work. I promise never to beat anyone over the head because his or her module naming doesn't conform to some standard; I don't have the stature. There is always the practical point that any module destined for CPAN may be submitted directly for review, at which time Wiser Heads can suggest the right name for it. (I do not suggest bypassing this step.)

The middle ground is often best. I would suggest that a writer of Perl, being an engineer, might be better served by prescription than the author of an English novel. Some will say both are artists and I don't disagree.

Replies are listed 'Best First'.
Re^4: Top Level Module Namespace Table
by ELISHEVA (Prior) on Oct 04, 2012 at 10:35 UTC

    Hidden in your "readmore" link is a comment about the Data:: namespace being the world's worst identifier. user::petdance's observations were in regard to "data" as a variable name. Variable names usually identify the content stored in the variable. I totally agree that calling content data is pretty pointless. By definition it is data. However, that is not the meaning behind the top level data namespace.

    Data:: as a namespace is short for "data structures" rather than for "data content".

    It's been my understanding that the Data:: space is most properly used for modules that manipulate data structures independent of content and purpose. For example, a set of list or hash navigation utilities would belong in the Data:: namespace.

    While it is true that nearly all modules use some sort of data, it isn't true that all modules are focused purely on the data structure itself apart from the use case. Most modules manipulate data for a purpose and the module is focused on the larger purpose (web page generation, database extraction, report formatting, user interaction, etc, etc.). Thus not all modules belong to Data:: even though they use data.

    Data:: also seems to be the home of several modules that transform one data structure into another or convert complex data structures to strings, but not all. String representations are often closely tailored to specific use cases (computer persistence vs. human readability) or recognized standards (JSON, YAML). These modules often end up in top level spaces named after the convention or use case for which they were specifically designed.

    Also without Data:: we would have the problem of where to place generic transformation utilities, particularly ones that manage bi-directional transformations between two or more equivalent storage formats and internal data structures: would they belong in the source data structure? There isn't one single source structure. The target data structure? There may not be one single target structure either. A special transformation top level category? If so, what should that top level structure be called if not Data? Transformations? A namespace called Transformations:: would be as vague as Data::. In a certain sense nearly all programs involve some sort of transformation.

    Another issue arises when modules are developed for complex data structuring systems, e.g. a database. One could argue that these are purely about data structure and manipulation rather than the use case. After all, a database is at heart just a fancy data structure that supports validated and possibly distributed persistence. On the other hand, if the data structuring system is large and complex enough it gets its own namespace,e.g. DBI.

    But even though these larger complex systems get their own top level namespace, it would not do to have separate namespaces for each possible complex data structure. There are too many possibilities. Having a top level category dedicated as a catchall for general purpose data structure manipulation saves us from having a multitude of top level categories dedicated to specific data structures.

    Update: cleaned up some typos.
[reply]
[d/l]
[select]

      In C, a data structure is called a (variant) struct; and if Perlers called a data structure a struct then I would urge a top-level namespace of Struct::. But since that's not the case, I don't have a ready solution. Perhaps we should start calling them structs. This would be easier than trying to mumble around HoHoA... erm, HoAoH... erm, object-like-thing.

      We have the more flexible data structures; they have the shorter name that requires less disambiguation.

      Death only closes a Man's Reputation, and determines it as good or bad. —Joseph Addison
[reply]
[d/l]
[select]
Re^4: Top Level Module Namespace Table
by Bill.Costa (Acolyte) on Mar 07, 2020 at 17:52 UTC
    I share your frustration in this regard. At the least there should be a tool that simply lists all of the current top-level names. It is all fine and dandy for the guidelines to say avoid creating a new top-level namespace, but there seems precious little help for a developer to find the right church for a new module, let alone the proper pew. If that tool exists, I'm having trouble finding it.
[reply]

      Its documented that before pushing a brand new distribution to the CPAN to ask around in places like here, modules@perl.org etc to get an idea on your naming. This is a particularly good approach for first-time CPAN authors.

      Perlmonks has definitely had a few requests of this nature over the years.

[reply]
[d/l]
Re^4: Top Level Module Namespace Table
by Bill.Costa (Acolyte) on Mar 07, 2020 at 18:01 UTC
[reply]

In Section Seekers of Perl Wisdom