the future is Supertool...
Keith Hodges
keith_hodges at yahoo.co.uk
Wed Aug 15 13:53:34 UTC 2007
Some thoughts
> The future , as Goran said on Supertool, is not Monticello.
> Monticello is good for some, but is not the silver bullet.
>
>
I dont agree with this SuperTool is the future approach, having lived
with MC2 is the future for all too long.
It has taken years for the use cases to form around the current tools
and some of these are non trivial. I expect any new tool will do the
easy stuff and fail to do the difficult stuff and we will be back where
we started. It takes a lot of effort and "going around the loop" to dot
all the i's and cross all the t's. So I think we would be better off
actually finishing one tool (MC) or even its successor (MC2) before
starting on another.
For example the case where you want to maintain several versions of the
one method in the image:
You want the original method to stay with its original package so that
when you save the original package that package does not get broken. You
want your changes to stay with your package so that that does not get
broken. This is not as easy as it sounds.
A second example, however you do it, the out-of-order loading supported
by MC1.5 requires a cache of not-yet-loadable elements, I call this the
orphanage. Orphans get rehomed once the parents arrive!
So whatever tool you come up with will have the same basic elements,
like MC1 has MCMethodDefinition MCClassDefinition
MCClassVariableDefinition etc and a loader to apply them, browsers to
look at them, differs to compare them etc. Why have 1 technology when
you can have 4. (MC MC2 SuperTool and SystemEditor)
I mention SystemEditor because I think that a persisted system editor
would make a useful binary package distribution format which only needs
SystemEditor to atomically load!
MC supports Diffs in theory, so the "packages are too big" argument can
be tackled.
I started to add changset support to MC1.5 as well. This makes sense
because MC already has browsers for all this stuff.
By all means improve the recent changes and change sets support, this
will help all tools to work better. But is the changeset functionality
not wired in a deep way in all of the forks that this is aiming to
support? Migrating everyone to this new scheme is not going to be easy.
Personally I think that MC1.5 with SystemEditor working (MC1.5 is ready
its SystemEditor that is not trested) would be a winning combination. I
also think that MC can be simplified and slimmed down a lot with
SystemEditor support working.
I am disappointed that we are unable to raise the effort to get
SystemEditor tested and usable. This is a bottleneck for all the
initiatives which want to use it MC1.5 MC2. and Supertool, so I think it
should be THE priority task. (I am a bit snowed under for now myself)
sorry for being overly cynical
Keith
> I wish some could help me for not having Monticello in the base image.
> Only we need a "Monticello loader" and people could load Ralph version, Avi
> version, Impara version, Keith version .
>
> Or none of this in a year from today when Supertool is builded and adopted.
>
> Edgar
>
>
>
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
>
>
More information about the Squeak-dev
mailing list
|