On Tue, 1 Apr 2003, Daniel Vainsencher wrote:

> Something I didn't understand - will our improved ability to find
> overriden methods come from changing the code model, or the textual
> format? I don't see what the text format has to do with this.

Well, the simple answer to that is, of course, that it's the code model
that matters and the textual representation is irrelevant.

However, the DVS code model is actually pretty intimately tied to
chunk format, which is a lot of what I don't like about it.  The model
objects are all just thin wrappers around fragments of source code, which
don't ever get fully parsed - just enough to compare them with other
fragments and see whether they represent the same method or class, so it
can tell which ones need to be loaded (and which removed).  Once this has
been done the relevant fragments are combined back into a subset of the
original changeset (plus some removal doits), and this is either saved,
opened with the ChangeList, or most likely filed straight in to effect the
changes.

It's this tight coupling that I'm trying to avoid.  In Monticello, class
and method declarations are modelled fully, and they can load and unload
themselves without using the changeset mechanisms at all.  On the whole I
view this as a good thing, since it allows you to modify the loading
mechanism directly, rather than modifying what the code in the generated
changeset looks like, and it's for this reason that I think that
notifications like the overridden method warning would be more easily
handled.  But it's also by doing this that you lose the natural tool
support given by using changesets for everything.

Now, which export format is used is a completely different matter.
Obviously the Monticello code model could still dump and parse itself to
and from chunk format.  This isn't really necessary for backwards
compatibility, however, in that it's trivial to export a .st from a
package for those who need it.  For storing and versioning packages, I
would prefer to go to something that parses cleaner and has better defined
semantics (what I'm using right now is a simple #storeOn: of the
declaration objects, which ends up looking a lot like chunk format but is
much easier to parse).

Soon, probably tonight, I'll release a version of Monticello (or, really,
a new version of DVS) that looks and acts exactly like DVS but has the
cleaner code model (which brings a few immediate advantages and the
promise of many more), and, at least as an experiment, uses a different
file format.  This ought to be a completely painless migration for those
using the current DVS; I intend to migrate Seaside development to it and
hopefully others will follow.

If I end up having to cave and write a chunk format parser for this code
model, well, no big deal.  But I think you're right that if the FileList
and SM both support the new format, who will care?  So then it's just a
matter of getting Goran to include Monticello in the SM load script, in
the same way that DVS is included now...

Avi