7 Nov
2008
7 Nov
'08
7:09 p.m.
Hi
I will implement the following and I would like to let you know so
that you can give feedback
when we do not merge a class and its metaclass the instance variable
of a metaclass could have
an instanceScope since it is true that the instance variable is an
instance one.
Now when we merge a class and its metaclass the class instance
variable should have a class scope since
from the base class it is clearly a class scope variable.
For shared this is simple they are shared and have a classScope.
Now from a user point of view I would like that an analysis does not
depend on whether we
merged or not the class and metaclass. So I will put classScope to
instance variable of the metaclass
even when they are not merged with the base class.
This way we always get the following situation
isntance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
Stef
7 Nov
7 Nov
7:56 p.m.
when we do not merge a class and its metaclass the
instance variable
of a metaclass could have
an instanceScope since it is true that the instance variable is an
instance one.
Yes
Now when we merge a class and its metaclass the class
instance
variable should have a class scope since
from the base class it is clearly a class scope variable.
humm...
class and metaclass variables will belong to one unique instance scope
I guess.
Why should the class variable be in a different scope? Especially
since a class variable begins with a capitalized letter, which is then
easy to differ from instance variables.
For shared this is simple they are shared and have a
classScope.
When a classes and their respective meta are merged?
Now from a user point of view I would like that an
analysis does not
depend on whether we
merged or not the class and metaclass.
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.
So I will put classScope to
instance variable of the metaclass
even when they are not merged with the base class.
This way we always get the following situation
isntance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
ah ok. It makes sense to me.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8:25 p.m.
On Nov 7, 2008, at 7:56 PM, Alexandre Bergel wrote:
Because originally an instance variable has the class scope while a
classVar has a class + class class Scope
when the importer asks for it.
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?
when we do not
merge a class and its metaclass the instance variable
of a metaclass could have
an instanceScope since it is true that the instance variable is an
instance one.
Yes
Now when we merge a class and its metaclass the
class instance
variable should have a class scope since
from the base class it is clearly a class scope variable.
humm...
class and metaclass variables will belong to one unique instance scope
I guess.
Why should the class variable be in a different scope? Especially
since a class variable begins with a capitalized letter, which is then
easy to differ from instance variables. For shared this is simple they are shared and
have a classScope.
When a classes and their respective meta are merged? Now from a
user point of view I would like that an analysis does not
depend on whether we
merged or not the class and metaclass.
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. So I will put
classScope to
instance variable of the metaclass
even when they are not merged with the base class.
This way we always get the following situation
isntance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
ah ok. It makes sense to me.
Cheers,
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
8:42 p.m.
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? 
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? 
8 Nov
8 Nov
12:32 a.m.
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:
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."
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?
8:30 a.m.
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:
_______________________________________________
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 > 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
8:59 a.m.
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:
_______________________________________________
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
9:54 a.m.
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Being happy is a matter of choice."
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:
_______________________________________________
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:
>>> 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
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
10:25 a.m.
I disagree that you lose the possibility of doing Smalltalk specific
analyses. You do not really gain more information from an analysis
point of view if you split them.
One thing you would lose is that by one glance over the unique name
you won't know whether an attribute is on the instance or class side.
Now you know because the name of the parent class is with '_class'.
But, as you proposed before, if you put 'class_' before the variable
or method you would solve that problem too.
So, here is my counter question :): Do you have a Smalltalk specific
analysis in mind that would only be possible if classes are split?
Cheers,
Doru
On Nov 8, 2008, at 10:07 AM, Stéphane Ducasse wrote:
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.
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Next time you see your life passing by, say 'hi' and get to know her."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:32 a.m.
I disagree that you lose the possibility of doing
Smalltalk specific
analyses.
This is true what I mean is a simple mapping.
for example I would not have to do select: on methods all the time...
this is more object-oriented when dealing with class/metaclass
separation.
You do not really gain more information from an
analysis
point of view if you split them.
One thing you would lose is that by one glance over the unique name
you won't know whether an attribute is on the instance or class side.
Now you know because the name of the parent class is with '_class'.
But, as you proposed before, if you put 'class_' before the variable
or method you would solve that problem too.
So, here is my counter question :): Do you have a Smalltalk specific
analysis in mind that would only be possible if classes are split?
see above. :)
now for example for modrian I would have a less direct model
but I agree this is why I introduce merging at the beginning :)
Cheers,
Doru
On Nov 8, 2008, at 10:07 AM, Stéphane Ducasse wrote:
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.
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Next time you see your life passing by, say 'hi' and get to know
her."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(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
_______________________________________________
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
"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
10 a.m.
So I will reask my original question: annotated with stress and tests
results so far.
I will implement the following and I would like to let you know so
that you can give feedback
=======
case one: when we do not merge a class and its metaclass the instance
variable
of a metaclass could have an instanceScope since it is true that the
instance variable is an
instance one.
(I checked in moose and class inst variable have a class scope in this
situation.
So we probably got this discussion long time ago.)
=======
case two: Now when we merge a class and its metaclass, the class
instance
variable should have a class scope since from the base class it is
clearly a class scope variable.
(this is what we have in moose right now)
For shared this is simple they are shared and have a classScope.
Now from a user point of view I would like that an analysis does not
depend on whether we merged or not the class and metaclass **from the
instance variable scope point of view**
-- Of course the analysis like system complexity depends on the merge
or not, there is no magic--
So I will put classScope to instance variable of the metaclass even
when they are not merged with the base class.
(in fact I checked and this is already the case in current Moose
implementation)
This way we always get the following situation
instance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
(apparently this is already implemented like that more or less).
So I will add some tests in SqMoose and port them to VWMoose with
sharedVariableSupport (later
for now I will focus on SqMoose).
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:19 a.m.
Ok, then it's decided :).
(indeed, we implemented class scope for attributes and methods from
the class side when Adrian redid the importer)
Doru
On Nov 8, 2008, at 10:00 AM, Stéphane Ducasse wrote:
So I will reask my original question: annotated with
stress and tests
results so far.
I will implement the following and I would like to let you know so
that you can give feedback
=======
case one: when we do not merge a class and its metaclass the instance
variable
of a metaclass could have an instanceScope since it is true that the
instance variable is an
instance one.
(I checked in moose and class inst variable have a class scope in this
situation.
So we probably got this discussion long time ago.)
=======
case two: Now when we merge a class and its metaclass, the class
instance
variable should have a class scope since from the base class it is
clearly a class scope variable.
(this is what we have in moose right now)
For shared this is simple they are shared and have a classScope.
Now from a user point of view I would like that an analysis does not
depend on whether we merged or not the class and metaclass **from the
instance variable scope point of view**
-- Of course the analysis like system complexity depends on the
merge
or not, there is no magic--
So I will put classScope to instance variable of the metaclass even
when they are not merged with the base class.
(in fact I checked and this is already the case in current Moose
implementation)
This way we always get the following situation
instance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
(apparently this is already implemented like that more or less).
So I will add some tests in SqMoose and port them to VWMoose with
sharedVariableSupport (later
for now I will focus on SqMoose).
Stef
_______________________________________________
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
"Presenting is storytelling."
10:27 a.m.
Ok, then it's decided :).
Yes I should have checked before.
I will fix then the merging and add the sharedVariable
(indeed, we implemented class scope for attributes and
methods from
the class side when Adrian redid the importer)
Doru
On Nov 8, 2008, at 10:00 AM, Stéphane Ducasse wrote:
So I will reask my original question: annotated
with stress and tests
results so far.
I will implement the following and I would like to let you know so
that you can give feedback
=======
case one: when we do not merge a class and its metaclass the instance
variable
of a metaclass could have an instanceScope since it is true that the
instance variable is an
instance one.
(I checked in moose and class inst variable have a class scope in
this
situation.
So we probably got this discussion long time ago.)
=======
case two: Now when we merge a class and its metaclass, the class
instance
variable should have a class scope since from the base class it is
clearly a class scope variable.
(this is what we have in moose right now)
For shared this is simple they are shared and have a classScope.
Now from a user point of view I would like that an analysis does not
depend on whether we merged or not the class and metaclass **from the
instance variable scope point of view**
-- Of course the analysis like system complexity depends on the
merge
or not, there is no magic--
So I will put classScope to instance variable of the metaclass even
when they are not merged with the base class.
(in fact I checked and this is already the case in current Moose
implementation)
This way we always get the following situation
instance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
(apparently this is already implemented like that more or less).
So I will add some tests in SqMoose and port them to VWMoose with
sharedVariableSupport (later
for now I will focus on SqMoose).
Stef
_______________________________________________
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
"Presenting is storytelling."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
8:51 a.m.
Hi guys
do you imagine that in fact the possibility to merge or not a class
and metaclass
is available since at least two years. So I do not really understand
what you are talking
about. Now I want to fix the lack of import of class variables and
also a bug I found
about instance variable of the class and the metaclass when merging.
Stef
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:
_______________________________________________
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 > 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
9:01 a.m.
On Nov 7, 2008, 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.
Yes
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? This means that there will be twice less classes in a
model.
It is already like that since two years you can ask whether you want
to merge or not.
A system
complexity view on a imported (using merging) smalltalk application
will be different than the one with no merging.
Of course so what? It depends what you want to see.
When you look at packages dependency it makes sense to merge,
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
5888
days inactive
5889
days old
17 comments
5 participants
participants (5)
-
Alexandre Bergel -
Michele Lanza -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba