Sounds like a plan to me. Do note that this does make the new format
packages somewhat 2nd class citizens, because not all tools will work
with them. One thing that could help, is the ability to easily read such
a package, and file it out, without actually creating or modifying
classes and methods in the image. This would let package users use
whatever other tools they wish, without loss of generality, just a
little convinience. Easier than a parser?

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> 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