Daniel Vainsencher danielv@netvision.net.il wrote:

goran.krampe@bluefish.se wrote:

...

And SMPackage again - is a "public" package used by others.

So my conclusion is that both concepts are valid and disjoint but we should try to NOT introduce any *more* of these "kinda-module-thingies" into the Squeak world. :-)

On the contrary - it isn't that we have too many "kinda module thingies", it is that we (ab)use the word "module" to describe an

I don't think we have too many either. I just meant that we only need ONE per construct - as you describe below. So in short we are in agreement - I just slipped with the words.

imaginary construct that's supposed to solve too many different problems. Here's one way to cut it -

• Unit of code reuse (which brings with it issues of understanding

changemanagement)

Yes, and here we have typical source management stuff like PackageInfo.

• Unit of program deployment (including issues of mixing different

versions of modules)

Right, that is where SMPackage fits.

• As used by some people, may also include Namespaces, distributed

transactions, partitioning of non-code objects...

ImageSegments, Magma etc I guess.

To the extent that we're clear about which design is meant to solve what problems, constructing the overall solution from a few more pieces won't hurt too much, and will give us flexibility (DVS today, Monticello tommorrow).

I agree fully. I was just trying to note that the seemingly similar PackageInfo and SMPackage (SMCard today) are still different beasts AND that we should be careful with introducing more constructs that try to solve the things *they* already solve. But other abstractions are of course completely ok. :-)

Or putting it another way - making a competitor to SM or DVS would be in many ways counterproductive since these tools in some ways work their magic by turning into de facto standards for the community. Much better to cooperate on them. :-)

And that is btw one of the reasons I really want opinions on SM. Since a few important issues were reaised on the list recently I am in the process of writing down how SM1.1 will work on:

http://anakin.bluefish.se/gohu/15

NOTE that it is a document in progress - I haven't folded in the thoughts from the recent discussion nor have I described my own plans in detail yet.

Daniel

regards, Göran