[squeak-dev] Monticello design question

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 -- http://mtfulmer.wordpress.com/

Matthew Fulmer wrote:
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: