Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > On Dec 2, 2005, at 7:31, Matt Diephouse wrote: > > [ Just a few notes, more to come. I've to read it some more times. ] > > > Naming Conventions > > > HLL Private Namespaces > > HLLs should use a namespace with an underscore and the > > lowercased > > name of the HLL to store any private items. For instance, Tcl > > should > > use the "_tcl" namespace to store the subroutines that make up > > the > > compiler. > > A compiler can use whatever. The created code should conform to the > final namespace spec.
The point of this is that if you need more than one compiler to compile some code, you don't want the compilers trouncing all over each other. The compilers need to use different namespaces for their internals and this is the only way that really makes sense. > > Class PMC API > > Class should inherit from the Namespace PMC. > > ... it seems to be unimplementable. A namespace is a class (PMC) that > defines it's API in terms of methods, which need a namespace for method > lookup, to locate the 'add' method, ... I knew this part was a bit shaky, I just didn't see quite why or how much. Thanks. > To me the whole namespace stuff can just be defined in terms of > interoperbility. One compiler alone can do whatever it likes. but *if* > the code should be usable by other languages, it has to conform to > fixed rules. > E.g. > - Namespaces should be hierarchical > > must be enforced for the 2nd case. > E.g. 'Perl5::CGI' can't be accessed by Python, but a canonical form > ['Perl5'; 'CGI'] can easily be created by the Python importer from a > pythonic name Perl5.CGI (which doesn't have quotes). That's exactly the point of all this. > I'm missing the policy in this proposal, e.g. what is allowed to be a > top-level global, how are HLL namespaces organized. And of course: > where is the Parrot namespace for it's PMCs. I don't think I follow this part. -- matt diephouse http://matt.diephouse.com
