<br><br><div><span class="gmail_quote">On 9/18/07, <b class="gmail_sendername">Göran Krampe</b> <<a href="mailto:goran@krampe.se">goran@krampe.se</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> - I personally don't like the "." notation for namespaces, especially<br>>> since we already use "." for statement separation. I still think "::" is<br>>> the best I have seen, although granted - this is a tiny, tiny detail.
<br>><br>> Meh. I like the dots; they look tidy. If you can give me a good reason not<br>> to use them then I'm happy to change.<br><br>A *good* reason? Hehe, not really. I don't recall the details in<br>
lexer/parser etc - adding support for $: inside global names was rather<br>simple - I have no idea if it is just as simple with $.<br><br>My reasoning behind :: was that it "stands out" in the syntax - you will<br>
not accidentally mistake it for something else. The "." is IMHO not at all<br>as clear. For example, what does this code say:<br><br> self add: Kernel.Array new: 4<br><br>Is it the same as?:<br><br> self add: Kernel.
<br> Array new: 4</blockquote><div><br><br>Hmm.<br><br>self add: Kernel.Array new: 4.<br>self add: Kernel::Array new: 4.<br><br>What do other people think?<br><br>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:
<br><br>self add: Array new: 4. <br><br>because Kernel has been added to the import list.<br><br>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.
<br><br>The change was this, in pseudo-diff format:<br><br>Scanner>>xLetter<br> "Form a word or keyword."<br> | type c |<br> buffer reset.<br> [c _ hereChar asciiValue.<br>+ ((type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type == #xDigit])
<br>+ or: [(type == #period) and: [(typeTable at: (aheadChar asciiValue)) == #xLetter]]]<br>- (type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type == #xDigit]]<br> ... more method code.<br></div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>> - Your Namespaces are linked to a Package scheme, I personally would<br>>> like
<br>>> to keep these concepts separate.<br>><br>> (background for people: Package is a subclass of Namespace and forms the<br>> root of a namespace hierarchy).<br>><br>> Why is this a bad thing? Could you be more specific?
<br><br>IMHO a package is a "deployment unit" more than anything else. A namespace<br>on the other hand is a "pool of unique names" that we developers share<br>with each other one way or the other.<br>
<br>I can see a package both using and defining names in several namespaces.<br>And I can see several packages defining names in the same namespace. Thus<br>I don't see the need for making a hard connection between the two
<br>concepts.</blockquote><div><br><br>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. <br><br>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).
<br><br>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!).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">BUT... I do of course see many good reasons of finding and reasoning about<br>
dependencies between packages by simply looking at the global names they<br>define or use. It has always seemed like the obvious "inputs and outputs"<br>of a package and I bet that we could very easily find 90% of all
<br>dependencies just by looking at these names.</blockquote><div><br><br>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.
<br><br>Gulik.<br></div></div>