We can try it out today if we want to. It has been a Squeaksource package forever. Why does everything have to be in the main image before it's "tryable"? We are going to all this trouble (well a couple of people are, but we all claim to want) to remove packages from the Squeak image to let people choose what they want, aren't we? But before we're even done we are already deciding that people wont choose it so it needs to be in the main image. Confusing, no?
On 9/19/07, Igor Stasenko siguctua@gmail.com wrote:
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.
-- Best regards, Igor Stasenko AKA sig.