Squeak and Namespaces

Andreas Raab andreas.raab at gmx.de
Fri Dec 1 10:47:50 UTC 2006


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



More information about the Squeak-dev mailing list