Hi!


> 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.

Mine is available on SM, I think Michaels is also available to taste.

> 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.

I agree. :)

> As for me, i see nothing 'groundbreaking' in removing global namespace
> (which is system dictionary).

My proposal does not remove it btw.

> 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.

Well, in many cases you are right. But in some cases it can get confusing.
Take a class named "Component" or "Manager" or "Date". But this goes to
the core of my idea, I want collisions to be "visible" but "handled"
instead of hidden away.

In a classical conventional approach you create a sandbox and put your
classes there. You can then create Seaside::TcpService and use it and
don't even notice you actually created a short name that is colliding with
another namespace (let's imagine KomServices had a Namespace too).

In my proposal these collisions are made visible in the sense that if a
lot of people use BOTH KomServices and Seaside (which a lot do) then they
will notice because even though everything WORKS FINE the references will
read out in qualified form and when you type TcpService (in a third other
namespace) you will be asked which one you mean.

I am saying this is GOOD because it will "gently guide" ourselves into at
least trying to not overloading the same names that other namespaces use.
At least those namespaces that tend to be used a lot together - and thus
occupy neighboring braincells in developers.

Recall that this is a HUMAN problem, not a technical one. HUMANS have one
single shared namespace that we try to keep track of stuff in. If lots and
lots of people start reusing the same short name for different things we
WILL get confused no matter if the computer is fine with it. :)

> 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?

Not *awful* but something we should try to keep at a reasonable level and
avoid if at all possible. My proposal making short name collisions
"visible but handled" is IMHO a mechanism to do that. If we use
"pessimistic sandboxes" we invite people to make duplicate short names,
IMHO.

> 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.

Agree.

regards, Göran