8 Nov
2008
8 Nov
'08
10:21 a.m.
Michele
I agree with you. the starting point of my questions (which were
stupid since this is nearly
already like that in Moose) was about the stability of information in
presence of merge/notmegre.
Not to question the possibility of merge or not. (see my other post to
doru feedback - I really need to be
able to model class and metaclass easily just for example to have a
simple model for mondrian hacking
- as you said we could have the merge all the time but the dsitinction
would imply more work.
Now I want the importer to do the work for me).
Stef
On Nov 8, 2008, at 8:30 AM, Michele Lanza wrote:
I understand where this is coming from (basically
everybody [including
myself] using Moose thinks that metaclasses are noise most of the
time, and one of the first things you do, is to "remove" them from the
model). However, if I think back to the possibly only major reverse
engineering experience on a very large Smalltalk system (the
MediaGenix system back in 2001) there we produced a couple of views
only about the (dark) class side, one of the questions being "where
have they gone meta in the system?".
The language independence is a valid argument, but following this line
of thought there you have the reason why Java interfaces are still
being modeled as classes where one has to use a couple of methods
(e.g., isClass, etc.) to establish what they actually are.
Coming back to Smalltalk, it looks like one would be giving up on
details that are there already, just for the sake of language
independence. And yes, the views about the dark side could also be
produced if the instance and class side are merged, it just takes a
bit longer, and makes the creation/conception of such views less
obvious.
Cheers
Michele
On 8-Nov-08, at 12:32 AM, Tudor Girba wrote:
Hi,
I think we should always merge the instance and class side. The
reason
is that I have never felt the need to have them separated in FAMIX,
because analyses are usually meant to be language independent. Anyone
else actually had a different experience?
Distinguishing between the types of methods and variables should be
just enough, and we can kind of do it from a language independent
point of view. I think that should be enough.
Also, if you have the instance/class sides separated you will
certainly have different results for analyses than if you have them
merged, regardless of what you do with the variables.
Cheers,
Doru
On Nov 7, 2008, at 9:00 PM, Michele Lanza wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Value is always contextual."
_______________________________________________
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?
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev