On 5/18/07, J J <azreal1977 at hotmail.com> wrote:
> Any interest in making a separate list or something for MC 2 discussion?  I
> have several things I would like to see happen with it and would be prepared
> (interested in fact) to contribute time on the project.
>
> The main goal I have for it is that the the system should use change sets as
> the base unit and in fact push more functionality down into change sets, and
> change set tools.  I have heard that their are bugs with change sets but
> that seems like a reason to fix the bugs, not avoid the use of change sets.

The problem is not that there are bugs with change sets.  Change sets
are mature, well tested technology.  I have been using them for 20
years and understand them very well.  The problem with change sets is
that they are fundamentally a bad idea.  Change sets are programs
which, when run, modify objects.  The objects that they modify are
classes, i.e. programs.  The purpose of MC is to provide a package
system and to make program definition more declarative, to make it
safer to merge versions, to see the difference between versions, and
so on.  MC is relatively immature and is full of bugs, but it is the
right way to go in the long run.

> [1] This is something I am dealing with now:  I am finishing up on adding
> recurrence rules to the ICal package, but I switched to 3.10 because I
> wanted to use the latest of Damien's dev images.  The problem is one of the
> classes in ICal calls #raiseSignal: which doesn't seem to work in 3.10 for
> some reason.  So to get my tests to pass (or at least test *my* code :) I
> just changed the #raiseSignal: call to use #signal:.

This was a mistake.  You are supposed to complain loudly on the 3.10
mailing list.  This is probably a bug, and the whole purpose of
releasing early and often is to find bugs.  But if people don't
complain about them, the process doesn't work.  We shouldn't provide
workarounds for bugs, we should fix them!

You are right that MC needs to allow for variations on packages, and
for changes that go across packages.  i suppose you could call these
"change sets", but they are not traditional Smalltalk change sets.

One of the problems with MC is that it doesn't have an explicit
representation of what goes in to a package, but instead relies on
names.  The name of a class's cateogry determins which package the
class it is in, and if a method is going to belong to a package other
than the package of its class, it must be in a protocol whose name is
'*' followed by the name of the package.  This was an expedient hack,
but it causes lots of trouble in the long run.  A package should just
be a list of classes and methods.  Perhaps the default is for all the
classes in one particular cateogry to be in the same package, but that
shouldn't be the rule.

It should be possible to have "overlay" packages, which override
certain methods in other packages.  Then you could put your local
changes in an "overlay" package.

Perhaps this is what you are calling a change set, but to me, a change
set is a file format that is a program that modifies classes.  MC
reprensents a package with a data structure that it can manipulate
safely.  We need to fix MC to do the things we need it to do, not go
back to change sets.

-Ralph Johnson