[squeak-dev] Future of Squeak, and outsider's view

Göran Krampe goran at krampe.se
Tue Jun 30 17:59:30 UTC 2009


Hi!

Eliot Miranda wrote:
> Arguably
> not.  (BTW VW has had it from 98).  The crucial difference is that in
> VW an extension can be in more than one package.  In Squeak a selector can
> only be in a single Monticello extension category.  That leads to the awful
> bug that when an MC package patches a base selector to extend it to fix a
> bug it ends up in the package and its membership of the package it was in
> previously being lost.  I understand that with method history this situation
> can be detected but if you e.g. condense changes then that history is lost,
> and the base package selector becomes only an extension  Ouch.
> 
> The VW "solution" is OK as far as it goes; a package is a set of class,
> selector pairs (more than this, but this is the essence).  An MC package is
> defined by class and method categories.  VW's parcels are intensional, MC
> packages are extensional.  There's a tension in both; many VW'ers want, at
> least at the UI level, for packages to be extensional, but precision
> (knowing whether something is in a package or not, allowing things to be in
> more than one package so that one can include patches, etc) requires an
> intentional construct.
> 
> When you also provide selector namespaces I don't think the situation
> changes because one still needs patches in the absence of a perfectly
> designed system.  So IMO somehow MC needs to move to an intensional package
> definition, at least for extensions ;)

Now, yet again I pull out from my hat... DeltaStreams! :)

If a package was defined as a Delta, then - since a Delta is a 
*completely standalone object* - you can never lose any information by 
loading another Delta into the image. NOTE: Loading is not the same as 
applying.

So if you have 2 Deltas loaded into the image (no changes have yet been 
made to the image!) you can analyze them and discover that they both 
include SomeClass>>someMethod - with conflicting code in them (otherwise 
we would still be kinda ok).

If you would proceed and apply first one (=make the changes to the 
image) and then the other you would of course end up with the last 
version of that specific method.

But fact remains - Deltas are *standalone* and can be loaded *before* 
you actually apply them. And you can revert them if all their changes 
are revertable.

Deltas can thus also be used as a "quilt" system (like Mercurial queues) 
where you can juggle Deltas and "shelf" / "unshelf" stuff etc.

Sorry, just couldn't help mentioning it.

regards, Göran




More information about the Squeak-dev mailing list