goran.krampe wrote:
>
>> 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.
>

I don't propose to throw away this information.

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

As Lex said: Everyone is almost always eager to use the newest version, 
because it is probably the one which works best. The module system should 
encourage to program modules which work together if you use the newest 
versions. I fear that your philosophy results in an inflation of versions, 
many of them half baked, many not working together.

For a sophisticated module system this is of course no problem, but it is 
one for the programmer. A module system has an effect on your style of work. 
If it is easy to produce, save and track interim versions or special 
versions for this and that, you will do so - the inflation of versions I 
talked of.

This maze of versions is not helpful by definition or by the fact that your 
module system can handle it technically! It is the opposite; programmers 
have to track these myriads of versions and interdependencies in their mind 
and waste time processing them. To strive for "one cardinal" version is an 
answer in the spirit of keeping things simple and the module system should 
reflect this, because it influences it.

>
...
>

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

You like to look at the module system from what your program (SM) does. But 
there is another perspective! These modules have to be at some point in the 
mind of a programmer - only sHe is the one who programs. It is not just 
hitting a button and writing out a "verified" configuration automatically. 
This is not trial and error or programming by an automaton. You have to 
think and communicate about what modules and versions are loaded and where 
and why problems could arise and how to test for them.

To make mental handling easier, it is best to compress and crystallize the 
information and implications a module contains into a name - language. UUIDs 
are mentally not helpful. Load scripts, emails and directory names are all 
examples where UUIDs shouldn't occur. Linguists have shown how the usage of 
different words while saying things equivalently, grossly influences 
thinking, judging and noticing. UUIDs are no words at all!

Again the specifications of the module system en- or discourage the usage of 
UUIDs. You, the master of SM, have it in your hands ;-)

regards Martin