Squeak and Namespaces
ramon.leon at allresnet.com
Thu Nov 30 22:03:18 UTC 2006
> Hi ramon
> The point that andreas raised is valid. My question is what
> do namespaces really bring us?
They would let me type User instead of SSUser, SPUser, KTUser, FAUser, and
if multiple User classes were detected, they'd ask me which one I meant.
And if one was in the current package, it could assume I meant that one and
not have me think about the prefix.
> (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.)
No, but I hear they aren't so great.
> ***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
That's not their intent. Their intent is to automate the prefix stuff so we
don't have to do it manually. Yes, SD::Foo would clash with SD::Foo... But
it won't clash with WA::Foo, ZW::Foo, or QT::Foo, which is how it helps me.
> 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.
Unnecessary in Goran's proposal.
> So conclusion simple namespaces do not help avoid clashes.
Yes they do.
> 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
> 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?
Manually prefixing classes to prevent name clashes, and being forced to use
those long names when the tools could do it for us, and hide it from us in
> Having shorter Class names? because this is not about name clashes.
> Namespaces do not solve that....
Namespaces do solve that. They let me have a Foo class in every project
without me having to manually prefix them all. To me... the name is Foo, to
the compiler/fileOuts, it's the long names which don't clash (WA::Foo,
> Now about traits. This is simple if people (that do not try
> For pragmas, do you see how important they are? We could have
I'm not complaining about Traits and Pragma's, they're great, I was simply
pointing out that those are major changes that have recently been adopted,
so why not this minor one that'd be such a great help?
> Why does it sucks?
> Really auto completion works, this is simple. It serves its purpose.
Because I don't like Hungarian style notations, my class name should be
about the class responsibility, it should have a prefix by convention just
to prevent me from clashing with other similar classes. I want to read and
write User, not WAUser or FFUser and Gorans proposal allows that.
> 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'll say it again... "Manually prefixing classes to prevent name clashes,
and being forced to use those long names when the tools could do it for us,
and hide it from us in the browsers."
This is Smalltalk... We shouldn't be doing anything like this "manually"
when the tools could so easily do it for us.
> Namespaces as simple as defined by goran will not solve this
> problem of breaking!
> Do not dream.
I didn't say solve... I said "so easily". Class extensions make
guaranteeing this difficult... But Gorans solution would help, for sure.
Perfection is not required to make progress. Gorans solution is progress
over what we have currently.
> 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.
Do programmers not scratch their own itches? If this topic comes up over
and over, and Goran has a solution that some of us think works... Then
obviously there is a problem, because somebody bothered to spend the time to
I think you're too concerned about what "can" and "should" be done, rather
than what "is" being done. The traffic on this thread alone clearly says
this is a big issue, if you don't see what Goran's solution solves, then
maybe it's not an issue for "you", but it's certainly an issue for me, and
for anyone coming in from another language, it's a huge issue.
I don't really care what "can" and "should" be done, those things don't
actually exist, they aren't reality. Reality is working code, and working
code, when proposed, should be looked at seriously, not compared to mythical
non existing solutions like someones idea of "real" namespaces and then
ignored on that basis.
> 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 ?
And again I'll say, it's a tiny fix that automates something that we do
manually now anyway, and is a pain in the ass. I don't like prefixing my
class names, it's ugly. I pump objects across web services to .Net, where
my class names are nice and pretty and simple, because .Net supports
namespaces, yet I'm forced to uglify them on the Squeak side because I can't
name a class something simple in Squeak and feel even mildly safe about
I'd have class name clashes with other projects of "mine". It's ridiculous
that I can't have three projects, each with it's own User class, without
being forced to MANUALLY prefix them, and READ and WRITE those prefixes
every time I touch code.
Gorans solution removes this burden, by objectifying the prefix, he can
parse it off and hide it from me. When I type a method that isn't found,
Squeak asks me which one I really meant; it can and should do the same thing
when I type an ambiguous class name like User. It should say hey, did you
mean WA::User, ZW::User, or QT::User, and then hide the prefix once
compiled. This one simple thing would greatly enhance Squeak in my eyes, and
I'd bet, in others eyes as well.
Gorans solution seems simple and elegant without actually changing much, or
bringing in the headache that apparently VW namespaces or full blown
namespaces really are.
Now, I don't have the expertise of many in this thread, I'm simply giving my
admittedly naive opinion. If there are any deep technical problems or
consequences to Goran's solution I'm unaware of, I'd certainly be more
cautious, but like I said... I can already create and use classes with
those names without his solution. His solution appears a simple bug fix to
More information about the Squeak-dev