On 19/09/2007, Michael van der Gulik <mikevdg at gmail.com> wrote:
>
>
> On 9/19/07, Igor Stasenko <siguctua at gmail.com> wrote:
> > On 19/09/2007, Michael van der Gulik <mikevdg at 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.