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