Squeak and Namespaces
stephane.ducasse at free.fr
Thu Nov 30 20:56:32 UTC 2006
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
> I see a lot of arguments for #3, wait for a better solution... but
> 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
Do not dream.
> seriously rocks, but nothing is beyond improvement, and maintaining
> status quo isn't always the best answer.
>> PS: what I see is that this anecdotal for now compare to all the
> 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?
My point is that if we want to improve Squeak there are a lot of
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?
> solution has this quality, it's simple, it's what we already do
> 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
because the solution of goran does not help there.
More information about the Squeak-dev