Hi!

"Michael van der Gulik" <mikevdg at gmail.com> wrote:
> On 9/18/07, G=F6ran Krampe <goran at krampe.se> wrote:
> > > - I personally don't like the "." notation for namespaces, especially
> > >> since we already use "." for statement separation. I still think "::"
> > is
> > >> the best I have seen, although granted - this is a tiny, tiny detail.
> > >
> > > Meh. I like the dots; they look tidy. If you can give me a good reason
> > not
> > > to use them then I'm happy to change.
> >
> > A *good* reason? Hehe, not really. I don't recall the details in
> > lexer/parser etc - adding support for $: inside global names was rather
> > simple - I have no idea if it is just as simple with $.
> >
> > My reasoning behind :: was that it "stands out" in the syntax - you will
> > not accidentally mistake it for something else. The "." is IMHO not at al=
> l
> > as clear. For example, what does this code say:
> >
> >     self add: Kernel.Array new: 4
> >
> > Is it the same as?:
> >
> >     self add: Kernel.
> >     Array new: 4
> 
> Hmm.
> 
> self add: Kernel.Array new: 4.
> self add: Kernel::Array new: 4.
> 
> What do other people think?

Let me just note that the second version using :: is NOT ambiguous for
the parser - the one using "." seems to be unless I am missing something
obvious.

> Keep in mind that I only expect people to use this syntax when the import
> list allows ambiguity in the names. Typically, you'd just see:
> 
> self add: Array new: 4.
> 
> because Kernel has been added to the import list.

Of course, and similarly goes for my proposal - you would very rarely
see or type fully qualifieid names there too. But again - I am trying to
put my finger on a parsing disambiguity here. :)

> What I am a bit concerned about is that I've made the BNF grammar more
> complex or that I've made it stupid. If a dot/period is followed by
> whitespace, it terminates the current statement; else it can validly be par=
> t
> of a word or keyword.
[SNIP of change]
> >> - Your Namespaces are linked to a Package scheme, I personally would
> > >> like
> > >> to keep these concepts separate.
> > >
> > > (background for people: Package is a subclass of Namespace and forms th=
> e
> > > root of a namespace hierarchy).
> > >
> > > Why is this a bad thing? Could you be more specific?
> >
> > IMHO a package is a "deployment unit" more than anything else. A namespac=
> e
> > on the other hand is a "pool of unique names" that we developers share
> > with each other one way or the other.
> >
> > I can see a package both using and defining names in several namespaces.
> > And I can see several packages defining names in the same namespace. Thus
> > I don't see the need for making a hard connection between the two
> > concepts.
> 
> I see nothing wrong with a deployment unit containing a pool of unique
> names. In my approach, a package does both use and define names in several
> namespaces.

Ok, so one package can define names in several different namespaces?
Ehh... that sounds slightly different than what I read - perhaps I
misunderstood the relationship between a Package and a Namespace in your
solution.

> What do you mean by several packages defining names in the same namespace?
> Are you talking about method overrides? Then like I said before, I can't
> work out how to do this without creating a security issue (I'm planning on
> Packages containing completely untrusted code which can be securely execute=
> d locally).

I am not talking about method overrides, no. I am simply talking about
package P1 defining a class X in N1 and package P2 defining class Y in
N1. Nothing magical. :)

But I think you wrote that Package is actually a subclass of Namespace
so perhaps your mental model of package == namespace is making this
sound *crazy*. :) But I still think these two concepts are orthogonal -
even though often we (developers on planet earth) *decide* that one
should be tightly bound to the other.

I see value in NOT making that tie, for once.

> If you're talking about defining the same class in multiple packages, then

No, I am not. :)

regards, Göran