Matthew Fulmer wrote:
>> It seems to me that a bit more structure in MC could greatly help for a 
>> variety of issues: From being able to provide a class definition with 
>> extension methods (and consequently being able to load packages into 
>> images that don't even have the classes originally being extended) over 
>> various simplifications and speed improvements in dependency management 
>> (e.g., the dependency sorter doesn't need to sort definitions that are 
>> contained inside other definitions since the dependency is implicit).
> 
> Well, at least the issue with loading extensions when the class
> is not present is a non-issue. This already works fine in MC1.5.

Right, and it's not really what I'm after. It was just interesting to 
note that there are several advantages to preserving the structure in 
the MC definitions which led me to wonder why it wasn't preserved.

>> However, it feels like this may have been a conscious decision and I am 
>> wondering what the advantage is to treat all definitions as a flat list 
>> instead of using the existing dependencies like class/method 
>> hierarchies. I am very seriously considering to change this and would 
>> like to know more about the potential impact of such a change.
> 
> But if you changed it, you would lose compatability with
> other versions of monticello, as the file format would be
> significantly different.

Yes, but I'm not sure it can be helped. My "real" problem is loading 
code in the face of namespaces and doing so without requiring syntax 
changes. This is trivial when you have structure; and pretty much 
impossible otherwise (or at least I haven't had a good idea for how to 
do it instead).

> I would say that MC1 should remain as it is with respect to file
> format. I would make changes like this in MC2 or DeltaStreams or
> something.

Unfortunately, "or something" is not an option ;-)

Cheers,
   - Andreas