Quick comparison of two Namespaces proposals

Michael van der Gulik mikevdg at gmail.com
Tue Sep 18 09:55:00 UTC 2007


On 9/18/07, Göran 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 all
> 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?

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.

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 part
of a word or keyword.

The change was this, in pseudo-diff format:

Scanner>>xLetter
    "Form a word or keyword."
    | type c |
    buffer reset.
    [c _ hereChar asciiValue.
+    ((type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type ==
#xDigit])
+       or: [(type == #period) and: [(typeTable at: (aheadChar asciiValue))
== #xLetter]]]
-    (type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type ==
#xDigit]]
    ... more method code.

>> - 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 the
> > 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 namespace
> 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.

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 executed
locally).

If you're talking about defining the same class in multiple packages, then
why would you do this? If you're talking about having the same Namespace
name (e.g "Collections.String") in multiple packages, then my approach
handles that fine (note to self: write a test for this!).

BUT... I do of course see many good reasons of finding and reasoning about
> dependencies between packages by simply looking at the global names they
> define or use. It has always seemed like the obvious "inputs and outputs"
> of a package and I bet that we could very easily find 90% of all
> dependencies just by looking at these names.



If there's a need, it is quite easy to make a tool that can show all
external dependencies of a package. It's currently quite quick to sort
through every namespace in a package and see what the dependencies are.

Gulik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070918/dc9b5291/attachment.htm


More information about the Squeak-dev mailing list