8 Nov
2008
8 Nov
'08
10:07 a.m.
I'm not convinced because it means as michele stating that we are losing
the possibility to build Smalltalk specific analysis and I want this
possibility.
Else I do not see why I invest in support SharedVariable support.
I need that for pharo analysis.
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.
now in moose we have nearly already implemented all the conventions I
proposed
I imagine that I thought about that before or for the first Famix st
plugging (read the new other email I sent).
Your original question was about putting isClassScope
and isShared
regardless of merging/not merging, and the rationale was how not to
break analyses.
Yes
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?)
itself when merging
and class when not.
I will rephrase. This is not really not breaking analysis since you
have to know what you are doing
but this is been consistent at the level we can and providing
stability when we can.
I have to check but a metaclass method should have a classScope
already and independently
to the fact that it is merged or not.
So at the end, next time I will check because we already have
everything except the shared
and the problem of name conflict between instance variables and class
instance variable.
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.
but the price is too high if I cannot analyse Smalltalk code with
moose then it is useless to me.
Stef
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Being happy is a matter of choice."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(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
--
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev