Hi -
I'm trying to make some modifications to Monticello and ran into an interesting issue: It appears that MC treats all definitions as a flat list and not structured in any way. E.g., MCMethodDefinitions are not contained inside the MCClassDefinitions that they apply to. Why is this?
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).
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.
Thanks for any info, - Andreas
On Wed, Apr 15, 2009 at 09:59:13PM -0700, Andreas Raab wrote:
Hi -
I'm trying to make some modifications to Monticello and ran into an interesting issue: It appears that MC treats all definitions as a flat list and not structured in any way. E.g., MCMethodDefinitions are not contained inside the MCClassDefinitions that they apply to. Why is this?
I don't know if there was a good reason originally to do it this way. You'd have to ask Avi, the original auther. Colin might know too.
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. If the class is not present, the extension definitions are saved in limbo in the "Orphanage" until the class is eventually loaded.
I also don't think sorting speed is really an issue. In my experience, the speed bottlenecks in both loading and saving are:
PackageInfo image-scanning speed the number of become:'s that happen during loading.
I have heavily optimized both of these operations in mc1.6.
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.
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.
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
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).
Unfortunately, "or something" is not an option ;-)
I have been thinking for MC1.7(or something) that with SystemEditor we can do away with the "Modelling" section of MC altogether. Since we load a flat model of definitions into a structured model of SystemEditor, and then ask SystemEditor to do the compiling etc. Why not just serialise the SystemEditor out to disk as the binary file format in the first place.
Keith
Andreas Raab wrote:
I'm trying to make some modifications to Monticello and ran into an interesting issue: It appears that MC treats all definitions as a flat list and not structured in any way. E.g., MCMethodDefinitions are not contained inside the MCClassDefinitions that they apply to. Why is this?
Simplicity. Working with a flat collection is just a lot easier most of the time. At the times when you do want a bit more structure, it's useful to create it on the fly and then throw it away again - you can use the structure that's most appropriate for the moment, rather than trying to make it match the "one true structure" of the domain.
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.
I've played with richer models of code a couple of times of over the years. There are certainly some benefits, but I think you just end up pushing complexity around - eg, from figuring out dependencies to maintaining the integrity of the model. It's probably telling that in MC2 we went the other direction, towards an even simpler model. MC1 represents history as a DAG of sets, while MC2 represents it as a set of sets.
On the other hand, that's a pretty nebulous gut-feel assessment of the trade-offs. It could certainly be done the other way. If you do go down that road, I'll be interested in what you come up with.
Colin
Hi Andreas,
This is only a speculation. If I remember correctly, there was the idea that Monticello could be used not only to version and merge code but other objects as well, e.g. instances of a business object model. As far as I know, no one took that route. However, maybe this was the reason why the definition model was not modelled more closely after the code model.
As for the potential impact of such a change: Sorry, I cannot help you there.
Cheers, - Bernhard
Am 16.04.2009 um 06:59 schrieb Andreas Raab:
Hi -
I'm trying to make some modifications to Monticello and ran into an interesting issue: It appears that MC treats all definitions as a flat list and not structured in any way. E.g., MCMethodDefinitions are not contained inside the MCClassDefinitions that they apply to. Why is this?
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).
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.
Thanks for any info,
- Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bernhard Pieber -
Colin Putney -
Keith Hodges -
Matthew Fulmer