When in fact we IMHO probably have these choices:
- Live on with "manual" namespaces using prefixes that
doesn't enable any proper tool support. We have them ALREADY
- don't deny it.
- Fix prefixes so that they can at least be used as proper
Namespaces and enable tool support and what not. It is just an improvement on what we ALREADY have.
- Wait forever for "stronger cool advanced" solutions that
will be presented, shot down and never enter the official Squeak. And during this perpetual wait we will still be using crappy prefixes, while arguing to death on squeak-dev about different models more incomprehensive than the next.
Wanna bet? :)
regards, Göran
I agree these are the real choices. We already manually prefix classes to avoid clashes, and it's absurd we don't have tool support for this idiom. If Traits and Pragmas can get included, surely something as simple as Göran's proposal which only objectifies an existing idiom can be seriously considered.
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.
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. :)
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. 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? What matters is not what "could" be done, but what "is" being done. Göran is bringing a solution to an outstanding problem to the table. Solutions are what should be given real attention, not problems. It's easy to point out problems, but very few people put a solution on the table, and apparently, he's been bringing this one up for a while.
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.
Ramon Leon http://onsmalltalk.com