Hi ramon
The point that andreas raised is valid. My question is what do namespaces really bring us? (Did you ever program in VW? Just give it a try. You will come up really fast with we need more tools support. Ok in VW namespaces are not that cool but they do more.)
***Namespaces will not let you load a code that have the same name.*** SD::Foo is the same as SDFoo. No matter how you want to read it. So if your code contains SD::Foo already then you are screwed . If you use the same namespace than me we will clash. The proof is that in VW you have to ***register*** your namespace on a wiki! yes on a wiki. So we could register prefix.
So conclusion simple namespaces do not help avoid clashes. VW people tried to explain to us that yes in certain occasion doing a private import in a namespace is the right action to do. because you can reuse your code and substitute other components...... Sure may in 1.9 % of the case and this is not the problem solved by the proposal of goran!
So I'm not against a solution to a problem but what is the problem we are talking about here? Having shorter Class names? because this is not about name clashes. Namespaces do not solve that.... Or you have to introduce visibility and visibility means that you need in some way the possibility to hide or show/import/ so you cannot have the butter and the money for the butter. Either you get the full power (I understand that for mickael he needs a scoping mecanism) or you get just the trouble of having first class namespace with tools showing you shorter names and you break the syntax. Now if we want to have import....this is not clear what is the best solution (at the package level? because it could make sense). This way the package would be more an container entity for shipping code.
Now about traits. This is simple if people (that do not try them) to not want them they can be removed and we will let the Perl, fortress, VW people having (and ruby with mixin) and enjoying them. Seriously my ego does not care. Telling that traits are in Perl-6 or Fortress is more important for my CV! And this is sadly true! Now I was sad that Alan Kay was mentioning in his Turing award presentation that traits were cool and that we did not have them in Squeak. As researchers this was an EFFORT to work on traits for squeak. We gained really nearly nothing because traits are old we cannot publish on them. We did that to give a chance to squeaker to try them.
For pragmas, do you see how important they are? We could have magritte without class side methods. We can have menus, tweak behavior....I think that they are really cool and I liked them a lot and I think that this was extremely smart from VW people to introduce them because they fit really well in Smalltalk. You see I can really have problem with VW namespace and really love their pragmas!
Stef
I see a lot of arguments for #3, wait for a better solution... but Göran's solution is much more pragmatic, and more importantly, available. If we can't formalize existing idioms, then it's highly unlikely something more advanced would ever fly, leaving us stuck with the status quo, manual prefixing, which sucks.
Why does it sucks? Really auto completion works, this is simple. It serves its purpose.
PS. To all recent Squeakers - Namespaces is a well known squeak-dev killer subject. It pops up EVERY year, creates tons of posts and never any real changes. I wrote my solution more than 2.5 years ago!!! Lord knows how the hell we got Traits into 3.9 - it is a bloody miracle. :)
But what solution really your solution solves? Really at the end of the day when I program what does it solves? What is the problem?
I'm beginning to see that. This is a serious issue that needs to be handled eventually. If Squeak is to gain a wider developer base, we need to be able to load packages without them breaking each other so easily.
Namespaces as simple as defined by goran will not solve this problem of breaking! Do not dream.
Smalltalk seriously rocks, but nothing is beyond improvement, and maintaining the status quo isn't always the best answer.
PS: what I see is that this anecdotal for now compare to all the tasks
that could improve squeak:
- more tests
- toolBuilder usage
- better packaged code
- clean dependencies
- removing dead code/broken code
Stef
No disrespect intended, but what is the point of this?
My point is that if we want to improve Squeak there are a lot of places where we can spent times: a good package dependencies mechanism that would help us building robust set of MC packages..... But I do not understand what is the problem that namespaces as designed by goran solve.
What happened to do the simplest thing that could possibly work? Göran's solution has this quality, it's simple, it's what we already do manually anyway, and I can already create a class named SomeSpace::SomeClass, I can even already create instances of it like (Smalltalk at: #SomeSpace::SomeClass) new. The only thing I can't do is reference it directly by SomeSpace::SomeClass.
Is what he's proposing really so objectionable? Really? It seems a minor bug fix that will enable tool support for existing idioms, why wait for some unwritten ultimate solution when we could have this now? Maybe I'm just too new and missing something, but I don't understand the resistance.
reply simply to this question (I still do not understand why I did not stay silent) what is a the real problem solved by this solution ?
note here that I do not take into account the problem mickael van gulik faces because the solution of goran does not help there.
Stef