Hi Martin!

Martin Wirblat <sql.mawi at t-link.de> wrote:
> Hi Göran,
> >
> >> On 15 juil. 04, at 17:19, lex at cc.gatech.edu wrote:
> >>> 3. Number two is, as you suggest, to have dependencies between
> >>> packages.
> >>> They do not need to be complex as we get going, but please do make
> >>> them
> >>> based on packages not particular versions.  At the distribution level,
> >>> the dependencies should be like "Scamper needs URL", not "Scamper 1.5
> >>> needs URL 1.3".  This is because, within a distribution, users almost
> >>> always want to have the newest versions of the packages.
> >
> ...
> >
> >I agree with you Stephane. IMHO the only thing that I can promise is
> >that a certain set of *releases* (=versions) work together. I can't
> >promise that the newest release of Y works with X 1.2, because that is
> >*in the future*.
> 
> Putting modules together is similar to "normal" programming, just on a 
> larger scale with a coarser granularity. We are expecting a Smalltalk 

Similar, yes. The same, no.

> Class to stay the same when we change something (minor) in it in the 
> sense that it should serve its clients the same way it did before. 
> Programming is speaking a language for our brains. Adding version numbers 
> would be an explosion of the vocabulary. To give classes or methods 
> version numbers would be nonsense. You want to assure that the core 

Well, have you seen ENVY? :) Or any project using CVS etc. One could say
that those projects have version numbers per class. Just saying that
"nonsense" is a strong word.

> functionality is as universal as possible and that it stays the same as 
> long as possible. Every programming style which does not adhere to this 
> principle is less efficient if not impossible. And because "moduling" is 
> programming, it is useful to work towards what Lex proposed quite some 
> times now, modules that work together regardless of there version.

Well, I have to disagree. I am of course in agreement "in general"
regarding the "should stay the same as long as possible" etc - but when
I change code I can not be sure I haven't made modifications that indeed
*will* break the clients. I may think I didn't break them - but you can
rest assured it will happen a LOT anyway.

So I am *still* convinced that when I have made a new version of X (I am
talking packages now), say 1.01, then I will test it with Y 1.93 and
when I see it works I want to record this information somehow. Now - why
on earth would I then say "the current X works with the current Y" which
means absolutely nada tomorrow, when I *can* say "X version 1.01 works
with Y 1.93"? It is simply *more information*.

Why would I want to throw that information away? If you don't care about
that information - feel free to try out X1.01 with a later version of Y
- but then you can not trust my testing of it!

It is all about recording known information and then having the ability
to draw conclusions and guesses from it. And thus I can not possibly see
why NOT recording the exact information would be beneficial - if it is
trivially easy to do so of course.

Btw, as you may know - there are new categories on SM mandatory for
releases. Maintainers that have made releases lately would have noticed
them. Those categories are meant to help you when you are eager to use Y
1.99 instead of the tested 1.93. I mean these:

	http://map1.squeakfoundation.org/sm/category/cb51b604-bb97-415d-a040-f2
31ecdd5bc7

I have also noticed there is one level missing there I think. At least
IMHO. That would be "Code changes, including additions" after "Code
changes, but only bug fixes". It would mean "Yes, I have changed and
added stuff, but clients should still work I think.".

> The same argument applies to UUIDs. Working with modules is programming, 
> and using UUIDs in the language necessary to do so, is a step backwards. 
> Please don't say here, that everyone can use names. Real world shows that 
> the UUIDs are creeping in everywhere. If SM modules will live up to what 

Can you specify "Real world shows" and "everywhere"?

> you hope for, we are going to have a Smalltalk with random vocabulary, if 
> we can't get rid of the UUIDs.

Random vocabulary?

You know - the only place I know of - where you today write UUIDs is in
load scripts. And you don't even HAVE to. And the only place you read
UUIDs would be in the URLs to the SM master server AFAIK.

Can you tell me where else these UUIDs are creeping in?

> To answer your original question, I think your work on SM is really great 
> and has made a big psychological impact on everyone interested in Squeak. 
> There is no need to fear that it may become obsolete just because a 
> somewhat different alternative may arise somewhere in the future.

Thanks. I also know that you have written quite a lot earlier on the
subject of SM and I appreciate the thoughts.
 
> regards 
> Martin

regards, Göran