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.
Interfaces: Generic and Typed
This seems to add complexity and I doubt it solves anything. The
import/export code has to deal with sigils and whatever. $Module::bar
variables are rare and usually there is another method to access such a
var.
.... This interface consists of the following methods:
Additionally to the debatable name 'add' ...
add($S0, $P0)
... in combination with ...
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, ...
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).
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.
And then we should look at implementation details.
My 2c so far,
leo
