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