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