On Wed, Sep 22, 2004 at 01:58:17PM -0400, Dan Sugalski wrote:
> Okay, this is going to be a three parter. The second part is entirely
> structural, and mostly a matter of convention. (It's second because
> the sensible thing to do is go over the link Tim posted to the
> previous discussion and more or less Make It So. I'm having a hard
> time getting a solid chunk of time together to do so, so it's second)
> The third part's the updated ops and implementation details, which
> need
?
> But the first part, in PHB-style bullet points:
>
> *) Our namespaces are going to be hierarchic.
>
> *) There are three things that can be in a namespace: Another
> namespace, a method or sub, and a variable.
>
> *) The names of namespaces, methods & subs, and variables do *not*
> collide. You may have a namespace Foo, a sub Foo, and a variable Foo
> at the same level of a namespace.
>
> *) Sub and method names *will* collide, so be careful there.
>
> *) If a language wants different types of variables to have the same
> name, it has to mangle the names. (So you can't have an Array, a
> String, and an Integer all named Foo) The only language I know of
> that does this is Perl, and we just need to include the sigil as part
> of the name and we're fine there.
Except if we want to share lexicals between languages. Which I'm not sure
we want to do at the moment. But, if I was trying to get a lexical scalar
that perl defined, I'd be somewhat annoyed if I had to do [set ${$a}]
in tcl. For many subs, we pass in the PMC itself, but there are cases in
tcl, for example, where I'd refer to the name of the array (which is how tcl
spells "hash") rather than pass in the array itself. For someone in perl
to remember to call this as
use Parrot::Tcl::main qw/array/;
my %hash = (1,2,3,4);
my $hash = "whee";
[EMAIL PROTECTED] = keys(%hash);
my @keys = array("names","%hash");
seems ugly. (This is, of course, a completely contrived example. =-) And
this may be perfectly acceptable to the insane people that
wish to do such things.
> *) Namespaces and namespace hierarchies may be overlaid. That means
> we look in the first hierarchy for something and, if we don't find it
> we look in the next, and so on. There will normally be a single
> namespace in force, but there may sometimes be multiple levels. (It
> allows for lexically scoped overridden namespaces and suchlike
> things, which are useful)
>
> *) No, you *can't* override individual slots on a namespace. You can,
> however, tie a namespace.
>
> *) Namespaces, by default, support notifications.
>
>
> I think that's it for the basic semantics. Discuss, if you will, for
> now. I'll get to work on part two.
