On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
On 9/19/07, Igor Stasenko siguctua@gmail.com wrote:
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
Array is a class, not a message. This is /not/ elegant and simply
doesn't
make sense. This is my last comment on this approach.
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
Unfortunately, this is important to discuss. It does end up becoming a bike-shed discussion, but in about five years time when most programmers in the world will be using Squeak, the namespacing syntax they use will be the result of this discussion.
I'm still undecided as to which syntax to use and open to suggestions. I'll give it a week or so.
Before we having a working namespaces system with working tools, we cannot get a taste of it, and therefore there's nothing to discuss about syntax of namespaces. Just release a code with any syntax you like and just note that It can be subject of change. Syntax is inferior to design. Changing syntax is a 10 minutes task, but changing system behavior to work with namespaces is not so straightforward. So, at first place we should discuss the design, which is most important thing.
As for me, i see nothing 'groundbreaking' in removing global namespace (which is system dictionary). I see nothing awful in having classes with same names in system, since they rooted in different categories (named packages/namespaces or something else) there's no way how you can get confused with ambiguousness. For example in package #Zoo , you can see a class #Duck and you know that its a duck :) and in package #Man-Moves, a class #Duck is something else. I see no ways how this can lead to ambiguousness and confusion. Everyone living with methods which have same selector, but doing different things for different classes. How making classes with same names, but doing different things can be considered awful and inappropriate?
So, i insist, that before saying 'no way, i never accept that', better give it a try and see how changes complicate or simplify development process.
Michael.