SmalltalkImage current

Hi,

I read in a posting from Andreas that there are problems
with the renaming from Smalltalkk to SmalltalkImage
current. I discovered problems with it several times
myself.
That remembers me that I wanted to ask what were the
reason to change it? It breaks a lot of code and reading
this list it appears to me that nobody likes it :) So how
came it has been renamed?

Btw. how much smalltalk images I'm able to run. new
is disabled. I don't get it.

Any hint is appreciated.

Norbert

2007/6/28, Norbert Hartl <[hidden email]>:
> I read in a posting from Andreas that there are problems
> with the renaming from Smalltalkk to SmalltalkImage
> current. I discovered problems with it several times
> myself.
> That remembers me that I wanted to ask what were the
> reason to change it? It breaks a lot of code and reading
> this list it appears to me that nobody likes it :) So how
> came it has been renamed?

I guess it's because Smalltalk is a global variable and global
variables should be avoided when possible.

--
Damien Cassou

  On Jun 28, 2007, at 10:09 AM, Damien Cassou wrote:

This is a good rule of thumb, and will tend to serve well when  
writing new code (and even for most refactorings).  However, for this  
particular case, I have not heard a compelling argument for how this  
change increases the utility of the system; to me, it seems to  
decrease it.

The costs are clear: code is uglier and longer to type, and  
compatibility is lost between different versions of Squeak.  Do the  
benefits outweigh these costs?  Let's see...

One justification for this change might be that it is a step toward  
not depending on that global variable.  This is simply not the case.  
In order to remove 'Smalltalk', a radical restructuring of the entire  
system would have to take place.  If there was a feasible technical  
and political plan for this restructuring, then changes such as  
'SmalltalkImage current' would be the most trivial and preliminary  
parts of the plan.  In other words, we are no closer to removing  
'Smalltalk' as a result of these changes.

'SmalltalkImage current' also early-binds a suggestion about how such  
a restructuring would look.  While it is laudable to aim for a  
loosely connected network of communicating Smalltalk images, it is  
not clear what role images themselves should play in structuring  
object interactions in such a system.  For example, the fundamental  
principles might instead be based on 'namespaces' for code and  
'islands' for objects.  The point is that we don't know; all we know  
is that 'SmalltalkImage current' and 'SmalltalkImage otherImageNamed:  
imageName' are almost certainly wrong.

To me, it seems that the costs and benefits were not carefully  
considered before the changes were made, because otherwise the  
changes would not have been made.

(even though I dislike this particular change, I have tremendous  
respect and appreciation for the efforts of Stephane et. al. to make  
a better Squeak).

Cheers,
Josh


>
> --
> Damien Cassou
>

On 28 juin 07, at 19:00, Norbert Hartl wrote:

> Hi,
>
> I read in a posting from Andreas that there are problems
> with the renaming from Smalltalkk to SmalltalkImage
> current. I discovered problems with it several times
> myself.

did you report them?
Where can we find how to fix them?

you can find the complete motivation in the archives but in a  
nutshell the point
was that Smalltalk is a namespace and that over time it agglomerates
a lot of extra behavior (sometimes junk) that has nothing to do with  
namespace management.
But with bookkeeping of the image. We tried to clean it up but we  
also stopped in the middle
since we were pissed off by complains.

> That remembers me that I wanted to ask what were the
> reason to change it? It breaks a lot of code and reading
> this list it appears to me that nobody likes it :)

Sure easy.....

> So how
> came it has been renamed?

It was not renamed behavior was moved out of SystemDictionary.

> Btw. how much smalltalk images I'm able to run. new
> is disabled. I don't get it.

me neither
>
> Any hint is appreciated.
>
> Norbert
>
>
>

On Fri, 2007-06-29 at 08:02 +0200, stephane ducasse wrote: I meant I had problems with software that had to be changed. And
yes I reported it. It was at least RemoteFramebuffer and Glorp
where I reported and provided fixes. Do you remember me trying to
contact Ian ?

> you can find the complete motivation in the archives but in a  
> nutshell the point
> was that Smalltalk is a namespace and that over time it agglomerates
> a lot of extra behavior (sometimes junk) that has nothing to do with  
> namespace management.
> But with bookkeeping of the image. We tried to clean it up but we  
> also stopped in the middle
> since we were pissed off by complains.
>
Ah, ok, cleaning up _is_ indeed a good motivation for doing it. Were
there alternative suggestions from those who did complain?
While this work is stopped in the middle of ... this is still a task
to compete it or to roll it back?

What makes me wonder is the fact that most of the bigger changes are
discussed here up front and very extensive. So I can't understand why
there were so much complaints _after_ the changes.
It sounds good. I'll have a look at it if I find some spare time. Just
to figure out what it's all about.

> > Btw. how much smalltalk images I'm able to run. new
> > is disabled. I don't get it.
>
> me neither
> >
Ok, now I understand why it is like it is. Thanks for explaining your
motivation. I didn't want to step on your excellent work I just wasn't
able to find anything useful on the net about this change.

thanks,

Norbert

stephane ducasse wrote:
> you can find the complete motivation in the archives but in a nutshell
> the point
> was that Smalltalk is a namespace and that over time it agglomerates
> a lot of extra behavior (sometimes junk) that has nothing to do with
> namespace management.

Of course the other way to look at it (which is more in line with
reality) is that Smalltalk is a representative for the environment and
as such includes both a name space and a set of attributes and methods
that relate to system-wide behavior. Such as platform information, vm
parameters, GC settings, startup/shutdown lists etc. which may be
delegated to particular places which implement them but where the
"natural" home (the place where the writers of the code wanted it to be
found) is in Smalltalk.

That was the prevalent opinion before the cleansing jihads started. At
the end of which we are in my opinion in a worse state than where things
started: More (and duplicated) code instead of less, no improvements in
clarity or understanding (it's just one utility class replaced by
another, more obscurely named one), depracation warnings and porting
woes. And for what benefit exactly? Saying "SmalltalkImage current
platformName" instead of "Smalltalk platformName"? I really urge people
to go back to 3.4 and compare Smalltalk back then with Smalltalk +
SmalltalkImage today to see if the price is worth paying.

I eventually got so tired about the whole mess that was left behind that
in Croquet I simply moved everything back from SmalltalkImage to
Smalltalk and only left delegation stubs in SmalltalkImage. So that if
you want to type your fingers bloody saying "SmalltalkImage current
platformName" be my guest; but really I won't make you. And it will be
compatible with other versions (except of course the latest Squeak.org
versions but that's not my choice to make).

Cheers,
   - Andreas

On Fri, 2007-06-29 at 01:04 -0700, Andreas Raab wrote: Ok, now I have a picture of what it was all about. I understand your
point and like to fully agree. Except for the point of delegating back
from SmalltalkImage to Smalltalk. Cleaning is an important point.
Cleaning at the cost of usability is not. I can imagine that it is good
to move implementation from Smalltalk to another place. I can also
imagine that there be more classes than just SmalltalkImage to keep
moved functionality. But then why it wasn't agreed to

- move implementation to the place where they are kept best
- delegate the functionalities from Smalltalk to there respective place

In my opinion that would be the best of both worls. Even if
SmalltalkImage would be a very great idea it would have been useful to
have a transition phase where the functionality is still reachable from
Smalltalk while the cleaning team has time to fiddle the right contruct
in the back.

For me it sounds sad that it led to a state of the image which is behind
a former status quo (I can't judge with my knowledge). And it doesn't
seem there are tensions to solve it in the near future.

I would opt for the sake of not breaking too much software that there
should be delegating message from Smalltalk to the SmalltalkImage ones.

Norbert

Il giorno ven, 29/06/2007 alle 01.04 -0700, Andreas Raab ha scritto:

> I eventually got so tired about the whole mess that was left behind that
> in Croquet I simply moved everything back from SmalltalkImage to
> Smalltalk and only left delegation stubs in SmalltalkImage. So that if
> you want to type your fingers bloody saying "SmalltalkImage current
> platformName" be my guest; but really I won't make you. And it will be
> compatible with other versions (except of course the latest Squeak.org
> versions but that's not my choice to make).

Interesting. Can I ask why you chose to move everything back to
Smalltalk and delegate from SmalltalkImage current to Smalltalk instead
of the other way around?
Would turning Smalltalk into a full-fledged facade object be a good
solution?

        Giovanni

On Friday 29 June 2007 11:32 am, stephane ducasse wrote:
> you can find the complete motivation in the archives but in a
> nutshell the point
> was that Smalltalk is a namespace and that over time it agglomerates
> a lot of extra behavior (sometimes junk) that has nothing to do with
> namespace management.
> But with bookkeeping of the image. We tried to clean it up but we
> also stopped in the middle
> since we were pissed off by complains.
That Smalltalk is just a namespace is not obvious. SystemDictionary's comment
reads "I represent a special dictionary that supports protocol for asking
questions about the structure of the system" :-(. In the absence of explicit
objects representing VM (SmalltalkVM?), object memory
(SmalltalkObjectMemory?) and so on, it is natural that methods gets
aggregated in Smalltalk.

"Smalltalk osVersion" looks easy and intuitive while "SmalltalkImage current
osVersion" is cumbersome and counter-intuitive because the image is OS
independent. osVersion makes sense only when an image is being interpreted by
a particular VM process. If we had a SmalltalkVM object, then "Smalltalk
osVersion" could be deprecated.

Of course, it is easy for me to say this now. hindsight is 20/20 :-)

Regards .. Subbu K. K.

Norbert

After trying to clean SystemDictionary  I think that at the end what  
should be done
(I proposed that but we did not do it at the end because we were burnt):
- is to keep Smalltalk as a placeholder for image related behavior  
like saving, abandonning sources,...
- have a namespace class which support class/global management
I proposed a migration path but (I did not have the energy to have a  
prototype of what I was proposing
May be I should- but back then I was burnt and sick of complains).

>>
> I meant I had problems with software that had to be changed. And
> yes I reported it. It was at least RemoteFramebuffer and Glorp
> where I reported and provided fixes. Do you remember me trying to
> contact Ian ?

But did you enter big reports in mantis because this is the only way  
to keep track
of bug and that we can fix and improve them.

We were always aware that we were introducing changes and that it  
would affect people
this is always this tension between moving and staying at the same  
place.

> Were there alternative suggestions from those who did complain?

Not to do it. Smalltalk is cool :)
Random refactoring...

> While this work is stopped in the middle of ... this is still a task
> to compete it or to roll it back?

We got sick of squeak. :)

> What makes me wonder is the fact that most of the bigger changes are
> discussed here up front and very extensive. So I can't understand why
> there were so much complaints _after_ the changes.


because it was incremental and not that discussed. Even if it makes a  
lot of sense
to have SmalltalkImage and SystemDictionary separate classes.

What I can tell you is that we always try to pay attention and this is
also why we got burn. We had this vision (dan one) that a system should
be lean and clean that people can really learn from it. Now some  
decisions
were made and may be they were not optimal....

Stef

On Fri, 2007-06-29 at 14:10 +0200, stephane ducasse wrote:
This sounds as the work has to be kept up. If there is a wishlist for
3.11 it should be placed onto it. No, at the same time trying to find Ian I was asking for the right
procedure to solve such kind of bugs. As neither RemoteFrameBuffer
nor Glorp are part of squeak I didn't come to the idea using mantis.
I'll take a close look at mantis and what/how tickets/bugs are
entered. And it is not clear for a newbie that trivial things like
"exchange Smalltalk with SmalltalkImage current" is to be put into
mantis. If it is just for the record then how should someone know? Yes, that is true. But if I remember it correct I noticed you as a
guy who often argues to keep the protocol of objects unchanged. And
that doesn't fit into my mind together with removing methods from
Smalltalk :) Maybe I don't get you right.
> > Were there alternative suggestions from those who did complain?
>
> Not to do it. Smalltalk is cool :)
> Random refactoring...
>
Stef, I don't understand this, except this is meant ironic. And than
I have problems understanding why.

> > While this work is stopped in the middle of ... this is still a task
> > to compete it or to roll it back?
>
> We got sick of squeak. :)
>
Same as above. I can't understand this.

> > What makes me wonder is the fact that most of the bigger changes are
> > discussed here up front and very extensive. So I can't understand why
> > there were so much complaints _after_ the changes.
>
>
> because it was incremental and not that discussed. Even if it makes a  
> lot of sense
> to have SmalltalkImage and SystemDictionary separate classes.
>
Does the release team have absolute powers? :)
I think this is completely normal. That is one reason why I like the
squeak community so much. There are a lot of guys with academic
background trying to make a good and valuable piece out of squeak. And
there are enough people working on concrete projects which most of the
time introduce hackish style things into the same thing called squeak.
And most of the time they meet on such a list like this one and the
discuss in a good way. That is a thing about squeak which is most
promising to me.

just my two cents,

Norbert

It may seem like there are arguments on on both sides as to where
something should "live", and that there is no right answer. But I think
there is actually a way to tell if an architectural question has been
decided correctly:

   The cost of making a change ought to be proportional to the size of
the problem, not proportional to the size of the code base.

Thus it is "bad" architecture to have methods on a "namespace" object if
(and only if) doing so violates the golden rule.

That might be the case if I have to sort though a lot of crap to tell
whether adding or even using something will work. While it is true that
adding anything to a "namespace" object increases the amount of stuff to
sort though, adding methods does not UNIQUELY do so. Every entry to a
SystemDictionary increases the volume in the same way as adding a method.

Another issue is the possibility of conflict. I.e., the name has already
been used for some other purpose. Again, the issue is true for methods
and for dictionary elements separately, but identically.

I think much of the potential problems are really tools issues. For
example, I don't have to worry about learning all the methods if the
tools show me elements from orthogonal contexts in separate groups.
(Namespace/conflict resolution by context is a little more fundamental.)

I can imagine someone thinking -- "This is all well and good, but the
tools are what they are. With the ones we have, I am encouraged to think
  of methods on a class as being part of that class, and having more
stuff on the class makes it too hard to learn, analyze, and decompose
for different purposes or deliverables."  I think this is actually quite
true, but it is not uniquely so for the question at hand -- methods on
the Smalltalk object. For example, it is also true for Piers Cawley's
idea to add a method to everything that behaves like a collection. With
the tools and the language as they are, Piers has more work ahead of him
than he should have to in order to create and distribute such an
extension and to know that it will be right.  But in the
SmalltalkDictionary methods case, I just don't see any overt violation
of the Golden Rule - even with current tools.

One of the things that excites me about Alan et al's new project is that
it seems to me to be dealing with this fairly head on.

Giovanni Corriga wrote:
> Interesting. Can I ask why you chose to move everything back to
> Smalltalk and delegate from SmalltalkImage current to Smalltalk instead
> of the other way around?
> Would turning Smalltalk into a full-fledged facade object be a good
> solution?

It is one possible solution. The reason I decided against it was that if
the natural home for those methods is in Smalltalk and if those methods
are primitives (which most of them are) then what is the point in
delegating again? Like, for example, Smalltalk>>vmParameterAt: which is
a comment and then a one-line primitive. Except that in the Squeak.org
versions the one-line primitive is replaced with a deprecation warning,
a no-comment, and a delegation to SmalltalkImage. And what's that good for?

So I decided that since most of the methods in SmalltalkImage are of
that kind it'd be more useful to move them back to where they belong and
have SmalltalkImage instead of Smalltalk be the facade. It also means
that one may be able to get rid of SmalltalkImage at some point (I'm
pretty sure Smalltalk is around to stay ;-)

Cheers,
   - Andreas

El 6/30/07 3:31 AM, "Andreas Raab" <[hidden email]> escribió:

> So I decided that since most of the methods in SmalltalkImage are of
> that kind it'd be more useful to move them back to where they belong and
> have SmalltalkImage instead of Smalltalk be the facade. It also means
> that one may be able to get rid of SmalltalkImage at some point (I'm
> pretty sure Smalltalk is around to stay ;-)
>
> Cheers,
>    - Andreas


Andreas:

I always like this view.
Ralph , I wish we could do the "revert to 3.4" for Smalltalk.
What is your point in this issue ?

Edgar

2007/6/30, Edgar J. De Cleene <[hidden email]>: Wow, Smalltalk really is Windows. You have to be compatible with every
mistake you ever made because your clients will refuse to update their
code. There is actually code you there that uses SmalltalkImage
current because it was written for 3.9 or 3.8. Do you seriously want
to give them deprecation messages?

Philippe

On Jun 30, 2007, at 12:42 , Philippe Marschall wrote:

What if the "SmalltalkImage current" thing was the mistake? Wouldn't  
your argument apply either way?

- Bert -

We wanted to have a real namespace class so that we could use it to  
have a better way of controlling
references (for security/classloader like things....) because  
Smalltalk is really weak to that respect.
I still think that having a secure modular but open and reflective  
system is a really important/exciting goal.

So the goal of cleaning SystemDictionary was to convert it into  
Namespace. May be it was wrong, still
having a separate class to deal with class management is really  
needed and subclassing from systemDictionary
was not a good idea, since there is far more than what is needed.

Now retrospectively I think that SmalltalkImage was a mistake and  
that creating a separate namespace class
was the way to go and that SystemDictionary should delegate to it.
Now SystemDictionary as a name for what it does sucks. If Smalltalk  
would point to an instance of SmalltalkImage
then we would not need all these SmalltalkImage current. And we could  
do Namespace smalltalk at: #Point instead
of Smalltalk at: #Point to query class existence.

Retrospectively it was also a mistake for me to invest in Squeak and  
in the future I will see if we can gather a
group of people that just want to have fun building a better system  
but not taking the responsibility of the rest.
Forking is the only way so it should that way.

Stef

2007/6/30, Bert Freudenberg <[hidden email]>: Sure.

Philippe

El 6/30/07 7:42 AM, "Philippe Marschall" <[hidden email]>
escribió:

> Wow, Smalltalk really is Windows. You have to be compatible with every
mistake
> you ever made because your clients will refuse to update their
code. There is
> actually code you there that uses SmalltalkImage
current because it was
> written for 3.9 or 3.8. Do you seriously want
to give them deprecation
> messages?

Philippe

We could keep SmalltalkImage.
Maybe is not a bad idea. And some could complete in some future
But compatibility seems more important now.

I don't wish image go blow . And I think masters time is important to waste
remembering only a particular Squeak is different.

Edgar

> We could keep SmalltalkImage.
> Maybe is not a bad idea. And some could complete in some future
> But compatibility seems more important now.
>
> I don't wish image go blow . And I think masters time is important to waste
> remembering only a particular Squeak is different.

I think it is always worth to also look at other Smalltalk
implementations. No Smalltalk that I know of puts all its image
related functionality into Smalltalk the root namespace. They all have
something like ObjectMemory, ObjectMachine, etc.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch