Ned Konz <ned at bike-nomad.com> wrote:
> I think that using a stub to load the .mcv files is much superior to 
> filing in their exported .st format (which also does none of the 
> above).
Definitely.

> And then if they load Monticello later, they can re-load the .mcv file 
> (or the SAR) and maintain the record of their local changes.
> 
> I suggest giving the user a choice: either load Monticello first 
> (which the SARInstaller can offer to do) or use the stub installer 
> and get the equivalent of the .st filein behavior.
> 
> As for the other things you mentioned:
> 
> Detecting missing dependencies: the stub can detect missing classes if 
> desired. I was thinking about having the stub batch the definitions 
> so that a partial load wouldn't happen.
How much of Monticello are you interested in adding to this stub? my
first suggestion (in a previous MC thread) *was* to identify a minimal
subset of MC that can do only smart loading. 

Since I consider MC to be a harmless dependency to have, I now think
other things on Colin and Avi's todo list are probably a higher
priority. If people feel that installing the whole of monticello is so
terrible, and installing half of it is much better, my opinion may need
revision.

> Prevent code mangling: in what way? The SARInstaller handles line end 
> mangling.
Classes defined with ProtoObject superclass because their superclass
isn't present.

> Prevent walkbacks: which ones?
The ones that happen when filing in methods for a class that doesn't
exist (because the package that defines it wasn't loaded before the
mcv).

Daniel