Squeak and Namespaces

On Nov 30, 2006, at 12:13 , Andreas Raab wrote:

> brad fowlow wrote:
>> Given that, do the merits benefit allotting a syntax change (a  
>> valuable commodity) that could begin to fork the world into ::-
>> dependent and ::-free code?   Or would it would be better to  
>> acknowledge that letter-prefixing is just about as good, and free,  
>> and already there, and hold out for a stronger solution without  
>> colonizing the code pool in the meantime?
>
> Bingo. That's precisely the concern I was voicing earlier.

Is there really a scheme of namespaces that would not support fully  
qualified names? Given that Göran's proposal basically suggests one  
way of expressing FQNs, shouldn't it be easily supported by any  
namespace implementation?

- Bert -

On Nov 30, 2006, at 9:45 , Göran Krampe wrote:

Indeed, which is why I am inclined to say "Put up, or shut up". Göran  
has a simple understandable implementation that people could at least  
try to see how it feels. Then there is Andreas' namespaces in Tweak,  
which are very similar to Göran's IIUC, but are not hooked up to any  
UI yet. Dan/Henrik had a complex implementation that people tried  
hard to understand or even use, so it was abandoned (although the  
#environment hooks are still tehre for further experiments). I don't  
think I saw another concrete proposal in code form.

- Bert -

>
> Actually, IMHO import lists like in Java or Python do not fit  
> Smalltalk at all. Sure, people want to use unqualified names in  
> their code. But in those file-centric environments, you know  
> exactly where to look to identify which local name refers to which  
> global name - you scroll up a few pages to the import list. Also,  
> these imports always travel with the code using them, because it's  
> in the same file.

This confirms why I have doubts about import. But this is intriguing.
don't you think that if package were first class they could be the  
compilation unit and get import attached to them.

> Not so in Smalltalk. As has been noted elsewhere, the compilation  
> unit is a method in a class. Consequently, you need either fully  
> qualified names, or have class-based imports. We already have a way  
> to express the latter (class pools [*]), and we may like to have a  
> way for the former. That's all.

Stef

Hi G"oran,

on Thu, 30 Nov 2006 13:04:00 +0100, you wrote:
...
> When in fact we IMHO probably have these choices:
...
> 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? :)

You have at least 1.99 supporters, already (counting you full ;-). And  
there came other +1's.

My concern is just 1 (in words: one) message send in distance away from  
your implementation, even if sombody'd replace #>~ by #:: :)

/Klaus

> regards, Göran

Hi Lex,

on Thu, 30 Nov 2006 13:06:54 +0100, you wrote:
...
Interesting. Then, when you ask for all references to Package and later to  
Pack, what are the respective results?

Is this under the assumption that atoms in name space are unassignable  
objects (like: classes); what happens when Pack := nil ?

/Klaus

>
> These are small improvements over Java, but I use them all the time.
>
> -Lex
>
>
>
>

On Nov 30, 2006, at 13:59 , Bert Freudenberg wrote:

That may sound a bit like me trying to stifle the discussion. Not at  
all.

Actually, I'd very much appreciate a competing proposal. Like, one  
that does not require a syntax change but still remains readable. Or  
one that does not require browser magic to transform the fully  
qualified names to short names. I'd just like to see any claims of  
superiority supported by something tangible to evaluate ;)

- Bert -

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 

Bert Freudenberg wrote:

Hello,
I have followed the discussion and would like to chime in.
What I have understood so far is that the proposal makes
it possible to separate the namespace name from the class
name by using a separator in the "traditional" class name.

How about having a class method that tells me what the
prefix of the class name is? It could do so by guessing,
or I can explicitly specify the prefix if I like to
do so, by implementing the method myself. Of course it has
to be consistent with the "traditional" class name, i.e.
the class name must really start with the prefix return
by this method.

Thanks,
Wolfgang

Bert Freudenberg <[hidden email]> writes:
> Not so in Smalltalk. As has been noted elsewhere, the compilation
> unit is a method in a class. Consequently, you need either fully
> qualified names, or have class-based imports. We already have a way
> to express the latter (class pools [*]), and we may like to have a
> way for the former. That's all.

That does sound onerous.  With an import list per method, you'd
probably end up with more than half your code being import statements!


However, suppose instead that a compilation unit was a package?  Most
imports would then be listed at the package level instead of the
method level.

Given this, you would then have two ways to find out the symbol, just
as in Java-land.  First, you could browse over to the definition of
the package.  Second--and in any scheme we devise--you could either
mouse over the identifier and see what pops up, or you could use
Squeak's cool "explain" feature.


-Lex

"Klaus D. Witzel" <[hidden email]> writes:
> >    import Deeply.Nested.[Package -> Pack]
> >                               "make Pack be a shortened"
> >                               "version of Deeply.Nested.Package"
>
> Interesting. Then, when you ask for all references to Package and
> later to  Pack, what are the respective results?

You mean like the alt-N tool?

That's a good question.  Thinking about it, it seems to all work out.
One interesting case to think about is when you click alt-N when you
are looking at the main definition of Deeply.Nested.Package.  If you
click alt-N there, then surely the tool should also show you
references to "Pack" in the above method.


> Is this under the assumption that atoms in name space are unassignable
> objects (like: classes); what happens when Pack := nil ?

It seems to work for any global names.  The Java hierarchical-names
part just turns the flat namespace into a hierarchy.  The Scala-ish
renaming and rewriting just provides, within a limited scope, short
names that are exactly equivalent to the long names.

(FWIW, I'm sure these tricks are used in other languages, too.  I'm
just showing where my experience comes from here!)


In general it's just like with what Goran describes where browsers
show you short names, but otherwise everything in the system is
processing the long names.


-Lex

Hi,

By default, the existing tools that create a new user give the new user a
specified subset of the existing SymbolDictionary instances.

> And if one is added you
> rebuild all the places the user is being implicit since he may now be
> talking about a totally different class even though his code didn't
> change?

If a new SymbolDictionary is added to the image then it is not visible to a
user till it is added to that user's SymbolList. Adding it to a user's
SymbolList only impacts methods that are compiled later. Compiled code
remains bound to the globals (Association) referenced when the methods were
compiled. If you wanted to change the bindings, you would need to recompile
the methods.

James

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.

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.

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

Sorry I wasn't clear.  In python (afaik) the "compilation unit" is the
scope, and in smalltalk the scope is the method.  I guess categories as the
scope could make sense.  Would you have a context menu on the category for
what imports you want for this scope, or how did you envision that?


_________________________________________________________________
Fixing up the home? Live Search can help
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG

Like I mentioned earlier, I need this feature for securities' sake, but I'm probably going to implement a completely different Namespace system for my own use.

I'm quite impartial to how Namespaces are implemented in Squeak and I think your proposal is fine, provided that I can remove it later if it gets in my way. Currently this seems trivial, and if people don't start making unnecessary prolific use of the new Namespace syntax then I could still re-use most of the existing code.

So.. +1 to your proposal from me.

Michael.

Hi!

"Michael van der Gulik" <[hidden email]> wrote:
I don't agree. I wanted it to be a single level by design. Simple.
Buckets of names. And I don't want them to be fine granular - they
aren't Categories - they are Namespaces. One per Project is well enough.
One for basic official Squeak is just fine - and in that particular case
we just use good ole Smalltalk.

And as I wrote in some other post - what does the hierarchy really mean?

> Arguably, we're not at that stage yet, and one-level Namespaces fix all our
> current problems. I've already been bitten by lack of Namespaces - I
> couldn't implement my own SocketStream because the name was already used.

Right! I did the exact same thing you know. :)

> - Don't *have* to use file/class/package level imports.
>
> Like I mentioned earlier, I need this feature for securities' sake, but I'm
> probably going to implement a completely different Namespace system for my
> own use.

Ok. So then you would be using imports purely for constraining lookup.
Could easily be added of course.
Btw, the core of my solution is now described in perfect detail (and I
just tweaked it so that it seems to work in 3.9):

        http://swiki.krampe.se/gohu/35

> I'm quite impartial to how Namespaces are implemented in Squeak and I think
> your proposal is fine, provided that I can remove it later if it gets in my
> way. Currently this seems trivial, and if people don't start making
> unnecessary prolific use of the new Namespace syntax then I could still
> re-use most of the existing code.

As I said - for basic official Squeak I don't think we should use it at
all. :)

> So.. +1 to your proposal from me.

Nice.

regards, Göran

> 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
> 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?

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.

> 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,
ZW::Foo, QT::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
> Stef

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
scratch it.  

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 ?
>
> Stef

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
doing so.  

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
me.

Ramon Leon
http://onsmalltalk.com

Hi Ramon!

I just have to say: Thank you, thank you, thank you. :)

Really. I mean it. You seem to understand my solution perfectly.
Sometimes I get the feeling I am insane. :)

Btw, please read and try the "core" I just prepared (currently only
tested in 3.9):

        http://swiki.krampe.se/gohu/35

This is the MINIMAL change we need to add to older Squeaks so that they
can deal with ::-code AFAIK. Needs to be tested a lot of course. :)

regards, Göran

Is that Henrik Gedenryd from Squeak 3.3?

From Google:

I copied this important information on a new swiki page with the title

> 'Name spaces':
> 
> http://minnow.cc.gatech.edu/squeak/2221
> 
> This page can be accessed from

> 'Modules: Design Principles'
> http://minnow.cc.gatech.edu/squeak/2044
> 
> which in turn is accessed from the 'Modules' page

> 
> http://minnow.cc.gatech.edu/squeak/2042

http://minnow.cc.gatech.edu/squeak/734

http://minnow.cc.gatech.edu/squeak/727

And here's the start of the 2004 Namespace thread :-)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/076817.html

Is there a document about Andrea's implementation on the web somewhere?

Michael.

Ramon Leon wrote:
> 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?

Because languages are not zero-sum games.

Cheers,
   - Andreas

> Ramon Leon wrote:
> > 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?
>
> Because languages are not zero-sum games.
>
> Cheers,
>    - Andreas

Touché.

Ramon Leon
http://onsmalltalk.com