7 Nov
2008
7 Nov
'08
9 p.m.
I'm not sure whether merging is the right way to go. One argument in
favor is that otherwise one ends up having a model full of "empty"
metaclasses, as the large majority of metaclasses do not implement any
methods. Visually this results in a system complexity view with dual
inheritance hierarchies. One argument against is that if a metaclass
does implement methods, in the case of a merge, the metaclass methods
would be mixed up with the "normal" methods (of course you would still
be able to differentiate them within the model). Merging would just be
trying to make up one (of the very few) shortcoming(s) of Smalltalk's
design. With respect to shared variables, that's another thing that I
think is a bit overengineered..
Cheers
Michele
On 7-Nov-08, at 8:42 PM, Alexandre Bergel wrote:
Maybe there is something I misunderstood. Merging classes and
metaclasses when importing means that one single class will represent
both the class and its metaclass I guess.
This means that there will be twice less classes in a model. A system
complexity view on a imported (using merging) smalltalk application
will be different than the one with no merging.
No?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
As far as I can see, an analysis may depend on whether
you merge
classes and metaclasses.
It seems hard to imagine than any analysis should be depend on
whether
there is such a merging.
you mean independent?
If we have the same data represented the same way independently of
merging
we favor that an analysis code does have to have different cases
based
on merging
or not?