Squeak and Namespaces

> 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. :)

No problem, it seems a simple elegant solution that solves 99% of my
frustrations without changing the feel of Smalltalk.

Ramon Leon
http://onsmalltalk.com 

I think I understand your solution pretty well.  Unless I am missing
something it is pretty simple:  You allow :: in the class name.  If it's
there it is used.  If the Class at the end (e.g. NS::OtherNS::Class) is
unique on it's own in the system then that is all that shows up in your
source.  If not, then every place that is ambiguous gets explicitly written
out by the compiler.  Right?

I appreciate all that you have went through to do something about this, and
I'm sure you have fought this battle many times.

But here is what I see personally:
- The way it works today seems good enough.  I know we are all prefixing our
stuff, but that doesn't seem that bad.  Maybe it's because I have only done
smaller projects so far so I am not strong on this point, I will take the
word of more experienced people (yourself included, but I'm not sure all the
votes are in yet).
- Suppose we use your system for the default.  At first there are no classes
that use it, and everything is still nice and pretty.  Then one day I
download some project that uses your namespaces a lot, and it happens to
define Array.  Now my entire image has "Kernel::Array" everywhere, right?

>I don't think addon namespace solutions will ever be used. I wouldn't.
>

I think you mis-understand me here.  I don't see the namespace problem as
pressing honestly.  Maybe I don't appreciate the pain this is causing
because I generally prefix my classes anyway.  But in a *business* you can't
wait for the perfect solution.  You have a dead-line that must be met.  So
having a drop in solution, even if it is a quick fix, is a necessity.  So
no, you wouldn't use an addon for personal things.  Neither would I.  But
for my company?  I have and will continue to.  There just isn't time not to.

>Hehe, rush? Are you aware of when I wrote this? Are you aware of how many
>posts I have written about it? Are you aware of how awfully many times the
>question of Namespaces have come up on the list? It is one of the "deadly
>subjects" always causing an explosion of subjective views and always end
>in nada.
>

No, I am not aware of all the history here.  But none the less, this is a
big issue as it changes the way Squeak smalltalk looks.

I was just discussing the problems with my first cut implementation.

_________________________________________________________________
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

+1.  Good points.


>

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

Yes, but here is the difference I see:  Right now we have MCDictionary (ok
we probably don't, but as an example) and Dictionary.  When I see
MCDictionary, no problem, I know its for MC.  And when I see Dictionary I
know it's a pure dictionary.  But with your solution, yes it stays like now
*for the moment*.  But you made this to get used.  Which means the MC people
will want to change MCDictionary to MC::Dictionary.  What happens then?  
MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses
of Dictionary become Kernel::Dictionary.  Right?  That's what I don't want.  
I realize I don't have to *type* it, but I don't want to *see* it.  It is
line noise for me.

>I agree. And yes, there is a cost. But people seem to think that we have
>these choices:
>
>2. Adding my solution now that gives us Namespaces that don't seem so
>impressive to all the language scientists (hey, no imports? It must suck).
>

I'm with you on the complexity of imports.  I know it can really suck in
other languages.  And in smalltalk I think it would be one of the rare
things that is *more* problematic then for other languages because you are
looking at a method at a time.  You would have to put the import statements
somewhere else (I think Andreas suggested with the package) and then simply
remember them since you can't see it anymore.  Or keep two browsers open for
every class you edit.

So it is a complicated problem end to end.  Of everything I have heard I
think the Gemstone (I think it was) solution was the best over all.  It
still has the problems with extra burden for programmer memory but you get a
lot with it at least.

>1. Live on with "manual" namespaces using prefixes that doesn't enable any
>proper tool support. We have them ALREADY - don't deny it.
>

Who denies it?  I think the disconnect here is simply:  you see this as a
huge, almost show-stopper level problem.  I personally see it as a minor
annoyance that actually gets amazingly close while still looking nice and
being explicit/obvious (i.e. less burden for the reader, and we all know
code is read much more then written).  I personally don't want the look of
(to me) a beautiful language to change for pain I just don't feel.

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

If the solution is right it will have a good chance to get adopted I would
think.  Traits was a pretty big change, but it fixed a real problem with
some huge pain.  And also, it hasn't changed how most of Squeak looks afaik.

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

These 3 Date classes are the result of difficult design decisions.

1) Seaside uses Duration, DateAndTime, Year, Month, Week, and maybe a
few other that are part of so-called Chronology.
These classes are not available in VW.
2) I was lazy and rather than re-implementing Chronology in VW, I ported
the Chronology package to VW.
3) Porting Chronology from Squeak to VW created name clashes for Date
and Time classes. VW namespaces
helped here with Core.Date and Squeak.Date, Core.Time and Squeak.Time.
Note that there is no clash for
Timestamp (TimeStamp in Squeak) and for Timezone (TimeZone in Squeak).
4) Now that I had two different classes for Date and two different
classes for Time, I had to decide which
would be used in VW Seaside. I did this by subclassing Squeak.Date and
Squeak.Time as Seaside.Date and Seaside.Time.
Again namespaces helped here.

I'm not that proud of the result that looks more like a hack, but it has
worked fine so far and without too much work.
Many Seaside add-ons like ShoreComponents, SeasideTesting, RSRSS port
nicely and silently to VW thanks to the hack.
A probably better solution would be to re-implement Chronology in VW
(with the ongoing desire to unify...). I feel however
that there might possibly be some potential semantic differences between
VW and Squeak in this area that would create
some different issues with some other difficult design decisions to come.

So, yes, VW namespaces helped (a lot!) to get Seaside ported to VW.

For your specific problem, rather than extending Seaside.Date with
methods that exist in Core.Date, you could also
change the superclass of Seaside.Date to be Core.Date. Then, you may
have to extend Seaside.Date with methods
that exist in Squeak.Date :-)

If some applications need Core.Date and some other need Squeak.Date,
then you can try defining different namespaces
and define MyNamespace.MyApp.Date and MyNamespace.MySecondApp.Date, and
extend them as needed :-).
That looks complicated but that would probably work.

Hi!

>>From: Göran Krampe <[hidden email]>
>>Yes, and let me here note that in my solution ALL references to globals
>>are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in
>>the SOURCE. Sorry for the caps, but this is VERY important to realize.
>>
>
> I think I understand your solution pretty well.  Unless I am missing
> something it is pretty simple:  You allow :: in the class name.  If it's
> there it is used.  If the Class at the end (e.g. NS::OtherNS::Class) is

No - I don't allow nested spaces. Only one level.

> unique on it's own in the system then that is all that shows up in your
> source.  If not, then every place that is ambiguous gets explicitly
> written
> out by the compiler.  Right?

Yes - but note that the SOURCE always contains the full name. Only the
*rendering* of that source in the browser decides whether to show the
prefixes or not.

I hooked into a low level spot for that and I think it works in all
browsers except the method version browser - need a special fix for that
one.

> I appreciate all that you have went through to do something about this,
> and
> I'm sure you have fought this battle many times.

:)

> But here is what I see personally:
> - The way it works today seems good enough.  I know we are all prefixing
> our
> stuff, but that doesn't seem that bad.  Maybe it's because I have only
> done
> smaller projects so far so I am not strong on this point, I will take the
> word of more experienced people (yourself included, but I'm not sure all
> the
> votes are in yet).

The funny thing is that people say that "how it works today seems good
enough" - in theory that sounds like a vote FOR my solution, not against
it. :) IMHO my solution is just an improvement on the current ad hoc
pattern.

> - Suppose we use your system for the default.  At first there are no
> classes
> that use it, and everything is still nice and pretty.  Then one day I

If you consider class names like WAComponent and SMAccount nice and pretty
- yes.

> download some project that uses your namespaces a lot, and it happens to
> define Array.  Now my entire image has "Kernel::Array" everywhere, right?

Well, first of all I mistakenly said in one post that the basic image
would use the Kernel:: space. That was wrong (it has been a while since we
discussed this before and my memory needed some kickstarting) - I instead
advocate basic classes to continue being in the current global space (=no
prefix).

And given that - then no, it would still say Array.

And also - even if we did introduce spaces for the basic classes - it is
still up to us/you to define the rules for space hiding/viewing.

>>I don't think addon namespace solutions will ever be used. I wouldn't.
>
>
> I think you mis-understand me here.  I don't see the namespace problem as
> pressing honestly.

Most of us don't - I wasn't the one bringing it up this time. I just
stepped up explaining it since my solution was brought forward on the
list.

Also - the solution would enable stuff that we don't know if we are
missing or not.

> Maybe I don't appreciate the pain this is causing
> because I generally prefix my classes anyway.  But in a *business* you
> can't
> wait for the perfect solution.  You have a dead-line that must be met.  So
> having a drop in solution, even if it is a quick fix, is a necessity.  So
> no, you wouldn't use an addon for personal things.  Neither would I.  But
> for my company?  I have and will continue to.  There just isn't time not
> to.

Sure.

>>Hehe, rush? Are you aware of when I wrote this? Are you aware of how many
>>posts I have written about it? Are you aware of how awfully many times
>> the
>>question of Namespaces have come up on the list? It is one of the "deadly
>>subjects" always causing an explosion of subjective views and always end
>>in nada.
>
> No, I am not aware of all the history here.  But none the less, this is a
> big issue as it changes the way Squeak smalltalk looks.

Of course, just don't say that we (the proponents of my solution) are
rushing anything. On the contrary.

In fact - I don't have any high hopes for my code ever entering the base
image. I continue to present it and tweak it but as long as we don't have
interest from the board (Bert voicing his support though was great and
hey, who knows) or from the current release team leader (whoever that will
be for 3.10) I don't think it will ever be adopted.

regards, Göran

Hi!

As I posted a minute ago - no, it would stay Dictionary.

Exactly. And there are other issues - like for example the fact that
writing a snippet in a Workspace (or any other text area) suddenly needs
to know what imports it is supposed to use...

It sounds like the "look" will be changed dramatically. We are only
stuffing in '::' between the prefix and the rest. It is not a HUGE
difference you know. :)

>>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.
>
> If the solution is right it will have a good chance to get adopted I would
> think.

Hehe, the problem with that line of thought is that "is right" is
subjective. The more complex solution the likelier it will piss off tons
of Squeakers that will stop it dead on squeak-dev.

> Traits was a pretty big change, but it fixed a real problem with
> some huge pain.

Really? A huge pain? I agree that Traits are great etc, but I would not
say that we had "huge pain" before we got them.

> And also, it hasn't changed how most of Squeak looks afaik.

That is just because they aren't used yet. :)

regards, Göran

Hi!

(should have replied to Brad, but for technical reasons I don't have the
original posting available)

But IMHO this is not a weakness in the Namespace design - it is instead
something we can deal with in numerous of ways on the tool side.

For example, I have played around with marking short names as "shy" which
would make them not appear in pop up menus and not force other non-shy
names to appear qualified. This would then be used for "private" short
names - it is like the inverse of an import, a non-export.

The problem is of course where to store this attribute - as a property on
the class would be neat but then we get the whole "backwards compatibility
problem", or perhaps we can pull an Avi-trick and use some Category
convention etc. etc.

But it doesn't *invalidate* the base solution.

Again - this is the NAIVE and SIMPLE approach - if there are multiple
short names we present them qualified. But there is no end to the tricks
or policies we can pull - for example, today in my implementation I still
show "local" references unqualified, because I think that is a good
compromise.

>>OK, that's an exaggeration...  but it's a choice.      Explicit
>>disambiguation (imports)
>>is mechanism that has a cost:  something more to attend to as a
>>programmer.
>>It also has a value:  it's part of a proven pattern for strong  namespace
>>insulation,
>>with all the grab&reuse freedom that comes with that.

I am unsure what you mean with "insulation" but my solution offers just as
"insulated" spaces AFAIK. You can't break code unless you collide with
namespace names - and all other systems I know of has that problem too.

>>If the insulation is porous (for instance, if other people's code can
>>affect,
>>and can change from day to day, what I see in my editor when looking  at
>> my
>>code)

But that is YOUR CHOICE. Just turn off the hiding and nothing changes. :)
Or we can add another tool setting where you tell Squeak what code is
YOURS and it could ignore the other peoples code when deciding if it
should hide prefixes or not. Etc etc.

>>then the proposal doesn't really give me namespaces... it's namespace
>>emulation.

No, it is not emulation. The spaces are separate - your space can never be
affected unless you file in code using the same namespace name - just like
in Java or whatever language.

>>But letter-prefixing is just as good as namespace emulation, and it's
>> more
>>honest;
>>it doesn't pretend (especially to newcomers) to be something it isn't.
>>And it doesn't require syntax adjustments or more editor pop-quizzes.
>>
>>Given that, do the merits benefit allotting a syntax change (a  valuable
>>commodity)

Please realize that the "syntax change" you refer to is about allowing $:
in *global references*. As both I and Ramon has made clear you can ALREADY
create globals/classes with $: in their name (!). Either *that* is a bug
or the fact that you later *can't reference them by their name* in your
code is a bug.

IMHO calling this a "syntax change" is a bit on the harsh side. Croquet
(or is it Tweak?) allowing positional argument syntax - that is a much
larger change IMHO.

>>that could begin to fork the world into ::-dependent and ::-free code?

Hehe, we have tons of other ways of making code "forked" - like depending
on Monticello or depending on Traits etc etc. As I have shown we are
talking about 4 method mods and one added method. All in all it is (let me
count)...

12 added lines and 7 modified lines of code. This is all you would need
AFAICT at this moment to have ::-code working, see:

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

I bet we can make this work in all Squeaks released to date with minimal
effort.

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

Ah, the "let's wait for something even better" argument. Well, it sure is
a killer. :)

>>Clearly, it's hard to wrangle a namespace change into this system.
>>A somewhat weak intermediate solution that got any uptake
>>could easily become a further moral hurdle
>>that a stronger solution would have to accommodate;
>>two kinds of legacy cases to reconcile,  rather than one.

Hehe, yeah... a "weak intermediate solution". So if I make it much more
complicated we can call it a Strong Enterprise Industrial Strength
Solution? :)

>>And I think that an environment where changes in unrelated code
>>could change, at any time, what text you see when browsing your own
>> code,
>>will strike people as a bit weird (to put it kindly).

Sure, weird and uncommon must be bad. Let's just turn Squeak/Smalltalk
into one of the "other languages" by emulating how they work - that seems
better - let's add imports and... hmmm, we could even start putting the
classes in files on disk - then it would be much simpler to find those
import statements! :)

Sorry for ranting. I am tired. No offense intended, really. And as I have
said - I have no high hopes so I don't know why I get worked up all over
again. Habit I guess.

regards, Göran

Göran Krampe wrote:
> Please realize that the "syntax change" you refer to is about allowing $:
> in *global references*. As both I and Ramon has made clear you can ALREADY
> create globals/classes with $: in their name (!).

No, you can not. You can create *symbols* with colons in it but that's
something completely different. I can also create a class like here:

Object subclass: #'Some Random Class with

#!@

in it'
     instanceVariableNames: ''
     classVariableNames: ''
     poolDictionaries: ''
     category: 'Kernel-Tests'

Try it, it works. Does that mean that spaces, carriage returns and
binary symbols must be supported in global references?

> Either *that* is a bug
> or the fact that you later *can't reference them by their name* in your
> code is a bug.

As the above example shows the bug is that the class name is not
validated. And yes, that is quite obviously a bug (which is even
somewhat funny since I did validate inst vars and class vars and pool
vars and about everything I could think of in ClassBuilder - just not
the class name itself)

Let me repeat: Language design is not a zero-sum game. I don't care if
the change is four or four hundred lines of code. I don't care if VW's
namespaces suck or if Croquet uses positional arguments. In *this*
discussion I care about whether a change like you are proposing is worth
it based *exclusively* on its own merits.

And if you are jealous that Croquet is able to make decisions you have a
simple alternative: Make up a fork that shows the error of everyone
else's ways. As a matter of fact I would vastly prefer that because it
would mean that there is some actual usage to look at and that I don't
have to take you at face value with all of these (so far completely
unsubstantiated) claims. The nice thing about forks is that you can look
at them, try them out, and then, with 20/20 hindsight can say whether a
change like it makes sense for Squeak in general or not. But I don't
think even you have used your namespace solution anywhere. So what
exactly are your claims based on?

Cheers,
   - Andreas

Hi!

Andreas wrote:
Right. I just wanted to get people to notice that we aren't that "Squeaky
clean" as we sometimes think we are. It sounded like an argument for my
solution and that I take back.

Well, in practiec I really don't think you don't care about that. :) If it
was four hundred lines I am pretty sure you nor anyone else would even
contemplate putting it in. :)

> I don't care if VW's
> namespaces suck or if Croquet uses positional arguments. In *this*
> discussion I care about whether a change like you are proposing is worth
> it based *exclusively* on its own merits.

I agree with the "on its own merits" of course. The point of noticing
Croquet "diversions" from regular Squeak is to get people to see that we
(as in all Squeakers - forks like Croquet included) are indeed already
changing things making various forks incompatible with each other.

I clearly recall this positional thing popping up in another thread when
someone was trying to get something from Croquet working in regular Squeak
(my memory sucks).

> And if you are jealous that Croquet is able to make decisions you have a

No, I am not jealous.

> simple alternative: Make up a fork that shows the error of everyone
> else's ways. As a matter of fact I would vastly prefer that because it
> would mean that there is some actual usage to look at and that I don't

The idea of forking Squeak has indeed occurred to me, but not for this
reason.

> have to take you at face value with all of these (so far completely
> unsubstantiated) claims.
> The nice thing about forks is that you can look
> at them, try them out, and then, with 20/20 hindsight can say whether a
> change like it makes sense for Squeak in general or not. But I don't
> think even you have used your namespace solution anywhere.

No, I haven't. I will though, but I don't think it will buy much more
insight than possibly flushing out a few bugs and add a feature or two. It
doesn't really say much about the larger picture.

> So what exactly are your claims based on?

I am slightly unsure what you mean with "claims". If you mean my claims on
how the code works - they are based on my own knowledge of what the heck I
did. If you mean my "claims" on how it would play out in practice on a
large scale it is of course pure guessing - in fact pretty much like
anyone else's "claims" on how another solution would work.

If there is any other claim you refer to - please specify.

> Cheers,
>    - Andreas

Let me just finish by saying that it was not *I* that brought this up once
again, ok? Someone asked about Namespaces in Squeak and Bert pointed to my
solution - and from there it went.

I am explaining and defending my solution, but I have generally given up
on getting it accepted - it is just the same story all over again. So you
don't have to worry. :)

I will try to document it in painful detail and will play with it myself -
but as far as advocating its inclusion goes, someone else will have to
step up.

regards, Göran

Bert Freudenberg wrote:
> 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?

There probably isn't a scheme that doesn't require some sort of
qualified names. However, what the exact semantics of those qualified
names is, is an entirely different question. For example, there is
already a significant difference between Goran's proposal and what is
currently in Tweak. Goran's proposal (as far as I understand it) is
effectively saying that the result of evaluating Foo::Bar is equivalent
to "Smalltalk at: #'Foo::Bar'" whereas Tweak treats it as "(Smalltalk
at: #Foo) at: #Bar" (with special exceptions for classes to appear in
Smalltalk to keep the tools happy). The difference? Well, how about
something like

   TextConstants::CR

which (in Tweak) works just the way I'd expect whereas in Goran's
proposal I have no idea what the intended result is.

And decisions about semantics like here *do* matter. For example, if one
agrees that the Tweak way is The Right Thing To Do, you'll immediately
notice that you get into deep trouble with Goran's "source code
beautifier" since you *can't* just write the abbreviated form (CR) and
writing the "full form" would imply that there is some other scope that
includes CR (which there may not) and determining whether a name needs
to be qualified or not suddenly needs to do a deep search of all
possible pools etc. etc. etc.

So the semantics of the FQNs are quite significant for their usage a
little bit down the road. And while it may be that Goran's proposed
semantics is just the right one it is equally likely that it's just the
wrong one.  And we haven't even started talking about static (compile
time) vs dynamic (runtime) lookup of names yet. In my understanding you
can only define the semantics of FQNs properly if you know what you want
to do with them.

Cheers,
   - Andreas

On Dec 1, 2006, at 8:49 , Göran Krampe wrote:
But if I have my own Array class it would then always show as  
My::Array, to be distinguishable from the core Array, right?

- Bert -

Hi!

I actually do it "both" ways right now. :)

The code on SM does it the way you say "(Smalltalk> at: #Foo) at: #Bar" as
can be seen on (#scopeVariable):

http://swiki.krampe.se/gohu/35.version?id=11

...and the code I wrote last night to get the minimal core working:

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

...does it like "Smalltalk at: #'Foo::Bar'" because then there is no
Namespace instance hanging at "Smalltalk at: #Foo".

Since this is compile time stuff (no speed requirement) I prefer the two
step lookup for obvious OO reasons. If we want it to work that way all the
time (even with the minimal core) then we need to make the core larger
(add Namespace class, make sure they get created and hooked into Smalltalk
upon class creation etc - I haven't looked through how much more changes
that would be).

As a sidenote I have not considered using this for anything else than
globals.

> And decisions about semantics like here *do* matter. For example, if one
> agrees that the Tweak way is The Right Thing To Do, you'll immediately
> notice that you get into deep trouble with Goran's "source code
> beautifier" since you *can't* just write the abbreviated form (CR) and
> writing the "full form" would imply that there is some other scope that
> includes CR (which there may not) and determining whether a name needs
> to be qualified or not suddenly needs to do a deep search of all
> possible pools etc. etc. etc.

If we would like to use it for non globals (such as pools, which I am not
sure I would like :)) then sure, it is not clear. I never intended to. One
way might be to just notice that, hey, this is not a global and just never
abbreviate it.

> So the semantics of the FQNs are quite significant for their usage a
> little bit down the road. And while it may be that Goran's proposed
> semantics is just the right one it is equally likely that it's just the
> wrong one.  And we haven't even started talking about static (compile
> time) vs dynamic (runtime) lookup of names yet. In my understanding you
> can only define the semantics of FQNs properly if you know what you want
> to do with them.

My solution was primarily compile time focused, but since we would have
Namespace instances hanging in Smalltalk (that acts like Dictionaries) it
also enables "normal" runtime lookup like:

   Foo at: #Bar

> Cheers,
>    - Andreas

Just giving you my thoughts/feedback, ok? :)

regards, Göran

On Dec 1, 2006, at 11:16 , Andreas Raab wrote:

Agreed, although the problem in your example is just that there are  
two competing uses of the :: qualifier. But in the case that you only  
have code with one semantic and syntax for FQNs, it should not be too  
hard to migrate to an extended semantic keeping the same syntax. It  
is hard or impossible to change the semantics completely, that is true.

Anyway - maybe you could explain your Tweak namespace semantics a bit  
more? It seems equally simple as Göran's but maybe could attract more  
followers? I'll copy the class comment below ...

- Bert -

[CNamespace class comment 'ar 3/27/2004 17:12']

WARNING: THIS IS UNFINISHED AS OF YET! But here's how it's supposed  
to work anyways:

Essentially, we don't want to screw with all of the existing tools in  
Squeak, so we just define that all classes are in the global  
namespace "Smalltalk" but that the names of the classes are really  
fully qualified ones. So, for example, the instance variable name  
'name' of class Bar in namespace Foo will contain #'Foo::Bar' and we  
merely fix the lookup so that the namespace contains an entry under  
#Bar which is found by the compiler. This allows us to leave all of  
tools alone working with the name of #Foo::Bar if they aren't  
namespace-aware and have the tools which *are* namespace aware to use  
#localName or #fullName as they desire.

This scheme has various advantages: a) You can reflect about all  
classes in the system by enumerating through Smalltalk (useful for  
system-wide tools). b) When we print an object (or inspect a class or  
similar) we will see it's full name which is good as it avoids  
confusion. c) If we want to "import" some class it will know where it  
was defined so we can track that dependency accordingly. Etc. This  
seems *hugely* advantageous to approaches which try to keep the  
"local name" of the class and do all sorts of guessing about "who  
this guy is" (say, Environment>>scopeFor:from:envtAndPathIfFound:) -  
after all if a class doesn't know where it is defined, who the hell  
*would* know?

So the basic approach here is: Classes know who they are and where  
they are defined, and we can ask them for a local name which will be  
a "shorthand notation" in their namespace.

The stuff that really doesn't work right now is to fix the tools to  
the point that they can deal with namespaces AT ALL. There are so  
many freaking places in the system that are hardwired it's almost  
impossible to fix them all at once. For example, there's an  
interesting issue with respect to defining classes - those class  
definitions *have* to be executed by the environment that defines the  
class but unless we want to change the class definition message  
(which would screw up even more tools) you can't really guess which  
name is being used. Argh... anyways if you want to see what I'm  
talking about try to define something like:

Squeak::Object subclass: #Object
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Tweak-Kernel'

inside the Tweak namespace. You'll see what I'm talking about...

Yes, well, depending again on your policy. If you play with it, it would
today probably show up as "Array" IF it is a reference from a method in a
class in My:: (a so called "local" reference). But again, this is just
policy.

For example, we might want My::Bar to show as "Bar" in code living in
My::, even if we have Foo::Bar in the system - BUT... if there is a Bar in
the system (a regular global - like Array) then we might want to show the
full name My::Bar *even* if it is a local reference - to make it very
clear that this is indeed not the regular Bar.

So in which situations we would like to only show the abbreviated name -
even when there are other such in the system - can be discussed at great
length - but it is just "policy".

regards, Göran

Göran Krampe wrote:
>>> I bet we can make this work in all Squeaks released to date with minimal
>>> effort.
>> Let me repeat: Language design is not a zero-sum game. I don't care if
>> the change is four or four hundred lines of code.
>
> Well, in practiec I really don't think you don't care about that. :) If it
> was four hundred lines I am pretty sure you nor anyone else would even
> contemplate putting it in. :)

No, I'm not sure about that. Traits were a *lot* more than four hundred
lines of code (and no syntax change, btw). But you're right that at the
point where it comes to implementation I would care about that. Yet, my
point here is that we're not discussing the implementation - we are
discussing whether a change like you were proposing makes sense at all.

> I agree with the "on its own merits" of course. The point of noticing
> Croquet "diversions" from regular Squeak is to get people to see that we
> (as in all Squeakers - forks like Croquet included) are indeed already
> changing things making various forks incompatible with each other.

It is extremely irritating to see these references to Croquet, traits,
pragmas etc. which have nothing whatsoever to do with your proposed
solution. So maybe you should stick to the benefits of your solution
instead of making references to completely unrelated projects?

> I clearly recall this positional thing popping up in another thread when
> someone was trying to get something from Croquet working in regular Squeak
> (my memory sucks).

Yes, in the OpenGL package. Which is (not coincidentally) the sole
reason why we added it to begin with. Because, if you're a 3D guy you
know OpenGL. And OpenGL has a *lot* of documentation that we could
leverage by making it possible to transcribe C-code from:

   glBegin(GL_QUADS);
     glVertex3f(0.0, 0.0, 0.0);
     glVertex3f(1.0, 0.0, 0.0);
     glVertex3f(1.0, 1.0, 0.0);
     glVertex3f(0.0, 1.0, 0.0);
   glEnd();

literally into:

   ogl
     glBegin(GLQuads);
       glVertex3f(0.0, 0.0, 0.0);
       glVertex3f(1.0, 0.0, 0.0);
       glVertex3f(1.0, 1.0, 0.0);
       glVertex3f(0.0, 1.0, 0.0);
     glEnd();
   yourself.

In other words you can copy and paste large portions of OpenGL code
literally into Croquet and I think that was completely worth it.

>> The nice thing about forks is that you can look
>> at them, try them out, and then, with 20/20 hindsight can say whether a
>> change like it makes sense for Squeak in general or not. But I don't
>> think even you have used your namespace solution anywhere.
>
> No, I haven't. I will though, but I don't think it will buy much more
> insight than possibly flushing out a few bugs and add a feature or two. It
> doesn't really say much about the larger picture.

You may be surprised about that. Speaking from my own experience just
being able to use a fundamental feature like this in your daily work
changes how you look at it. Because *wherever* you go you have the
option to use it and when you had that chance for a couple of months and
look back and say "so why did I use it here and not there and what would
need to be true for me to use it there" is *extremely* helpful for
understanding your own implicit motivations and what you expect from the
solution you originally designed.

> If there is any other claim you refer to - please specify.

No, it's just those - does that solution actually buy you anything in
the long term, how do you use it in daily work, does rewriting your
source code get annoying etc.

> I am explaining and defending my solution, but I have generally given up
> on getting it accepted - it is just the same story all over again. So you
> don't have to worry. :)

The funny thing is that like I said initially I don't even care all that
much but for some reason you get totally defensive about these issues.
And there are things I simply won't let slip by like factual errors
about what is and what is not true in the current system. If you want to
advocate your solution, go for it, just don't do it based on provenly
false claims (like "you can already use colons in class names so we must
support this in global references" which will make me respond every
single time).

Cheers,
   - Andreas

Hi!

Mmmm, we are using them as examples of changes to the syntax and language
- which they clearly are - and which this clearly is too. There is nothing
wrong in doing that. If that annoys you, too bad. ;)

I probably agree and have never said it wasn't worth it.

Yes, might be so - ask me in a year or so.

>> If there is any other claim you refer to - please specify.
>
> No, it's just those - does that solution actually buy you anything in
> the long term, how do you use it in daily work, does rewriting your
> source code get annoying etc.

Ok, gotcha.

>> I am explaining and defending my solution, but I have generally given up
>> on getting it accepted - it is just the same story all over again. So
>> you
>> don't have to worry. :)
>
> The funny thing is that like I said initially I don't even care all that
> much but for some reason you get totally defensive about these issues.

Mmmm, perhaps I do - I apologize for that. I have tried not to :).

> And there are things I simply won't let slip by like factual errors
> about what is and what is not true in the current system. If you want to
> advocate your solution, go for it, just don't do it based on provenly
> false claims (like "you can already use colons in class names so we must
> support this in global references" which will make me respond every
> single time).

I should have written that "you can already *create* classes with colons
in their class names" - which is true no matter the reason. And AFAIK I
did write that it probably was a bug, right? And I did take it back as an
actual *argument* - which it was not really meant to be, I was more trying
to indicate that things aren't that well defined as some may think.

regards, Göran

Hi!

So far this seems IDENTICAL to my solution, modulo any misunderstanding on
my part.

This part I need to test to understand the problem. :) I don't have a
Squeak handy right now but if the intention is to create a class
Tweak::Object, then why not name it that?

regards, Göran

"Frank Mueller" <[hidden email]> writes:
> one thing I really love in Smalltalk after programming years in
> different languages (and since 1996 in Java) is the simplicity and
> the really straight concept. One point is, that I don't have to deal
> with imports (or my IDE doesn't has to deal with it), I just wirte
> the class name and it's OK. All I need is in my image. Oh, yes, many
> of those classes have a little prefix of two or three chars, but who
> cares? That makes it allways clear, which implementation I use. So
> even in VisualWorks I use my TLAs as prefix, it makes live more
> simple.


Yes, it is a very nice thing about the Smalltalk feel.

It seems that you run into problems, though, when you scale from one
thousand classes simultaneously loaded, to tens of thousands, as is
happening with Squeak over time.  With such a large number of global
names, a hierarchical naming scheme is very helpful.  At the same
time, working with hierarchical names is inevitably less convenient,
because you have to deal with prefixes and imports all the time.

It points to an interesting goal namespace-system designers might
think about: can you make a system that scales in both directions?
Can you have a system with hierarchal names, out of which you can
build a nice Smalltalk80-ish 1000-name subspace where you do not need
prefixes and imports?


-Lex

Wolfgang Eder <[hidden email]> writes:
> 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.


Just to toss in my votes:

1) I am not sure that SM::Package is an improvement over SMPackage.
It does not look like a large improvement, anyway.


2) A general hierarchy is an improvement over one-level.  If you have
a project with 1000 classes in it, then you need multiple namespaces
within your project, and you want to group them under an umbrella
identifier of your project.  Without hieriarchical names, you will
have to invent a prefix for all your namespace names....



-Lex