Hi!
"Michael van der Gulik" mikevdg@gmail.com wrote:
On 9/18/07, G=F6ran Krampe goran@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