Quick comparison of two Namespaces proposals

Jason Johnson jason.johnson.081 at gmail.com
Wed Oct 3 21:25:07 UTC 2007


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 at gmail.com> wrote:
> 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.
>
>



More information about the Squeak-dev mailing list