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