On Sat, 25 Mar 2000, David Ascher wrote:
This made me think of one issue which is worth considering -- is there a mechanism for third-party packages to hook into the standard naming hierarchy? It'd be weird not to have the oracle and sybase modules within the db toplevel package, for example.
My position is that any 3rd party module decides for itself where it wants to live -- once we formalized the framework. Consider PyGTK/PyGnome, PyQT/PyKDE -- they should live in the UI package too...
That sounds good in theory, but I can see possible problems down the line: 1) The current mapping between package names and directory structure means that installing a third party package hierarchy in a different place on disk than the standard library requires some work on the import mechanisms (this may have been discussed already) and a significant amount of user education. 2) We either need a 'registration' mechanism whereby people can claim a name in the standard hierarchy or expect conflicts. As far as I can gather, in the Perl world registration occurs by submission to CPAN. Correct? One alternative is to go the Java route, which would then mean, I think, that some core modules are placed very high in the hierarchy (the equivalent of the java. subtree), and some others are deprecated to lower subtree (the equivalent of com.sun). Anyway, I agree with Guido on this one -- naming is a contentious issue wrought with long-term implications. Let's not rush into a decision just yet. --david