Squeak and Namespaces
ramon.leon at allresnet.com
Thu Nov 30 16:47:58 UTC 2006
> When in fact we IMHO probably have these choices:
> 1. Live on with "manual" namespaces using prefixes that
> doesn't enable any proper tool support. We have them ALREADY
> - don't deny it.
> 2. 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.
> 3. 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
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
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.
More information about the Squeak-dev