Hi Stef,
I read your original mail, and I said that I think all the trouble is really not worth it, because in fact it would be better to just not split the classes in the first place.
Your original question was about putting isClassScope and isShared regardless of merging/not merging, and the rationale was how not to break analyses. I know that since 2 years we can choose to merge or not and I like that, but now I say that we do not really gain anything by even considering not merging, because in fact you will break analyses in one way or another (for example, what should FAMIXClass>>instanceSide return?)
If we merge, then the variable problem because straightforward, as you know. Furthermore, if we merge we will also make Smalltalk fit the language independent paradigm of FAMIX.
Cheers, Doru
On Nov 8, 2008, at 8:59 AM, Stéphane Ducasse wrote:
Guys
Do you ever read my mails? I was never considering abandoning class and metaclass separation. Then I would not spend/lose my time to introduce support for ClassVariable if I would only focus on language independence. A side note you can ask the importer to **merge or not** since two years so what is the problem? You can decide for your experience what you want to do. Now reread my original question to understand what I was proposing.
Still you are not replying to my original question so I will do it the way I want but people should not complain that I did not try to have a discussion on the topic.
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:
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:
> 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Value is always contextual."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Being happy is a matter of choice."