Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
If A -> B, it should mean that - A has an outgoingInheritance to B, and - B has an incomingInheritance from A.
I fixed the descriptions now.
Doru
On Jan 31, 2008, at 7:38 PM, Adrian Kuhn wrote:
Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
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
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
I dont understand, is it as follows?
A superclass B subclass
cheers, AA
On 31 Jan 2008, at 21:20 , Tudor Girba wrote:
If A -> B, it should mean that
- A has an outgoingInheritance to B, and
- B has an incomingInheritance from A.
I fixed the descriptions now.
Doru
On Jan 31, 2008, at 7:38 PM, Adrian Kuhn wrote:
Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
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
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I = A -> B, I is the inheritance definition between A, B such that: - I subclass = A - I superclass = B - A outgoingInheritance includes I, - B incomingInheritance includes I.
I think the confusion is because we actually never used the incomingInheritance and outgoingInheritance, because these are derived, and before we only saved in MSE underived attributes. So, before we only counted on the subclass and superclass definitions, and they are the correct ones.
But in the latest version it is fixed.
Doru
On Feb 1, 2008, at 12:17 AM, Adrian Kuhn wrote:
I dont understand, is it as follows?
A superclass B subclass
cheers, AA
On 31 Jan 2008, at 21:20 , Tudor Girba wrote:
If A -> B, it should mean that
- A has an outgoingInheritance to B, and
- B has an incomingInheritance from A.
I fixed the descriptions now.
Doru
On Jan 31, 2008, at 7:38 PM, Adrian Kuhn wrote:
Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
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
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
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."
If you are consistent with UML convention, then A -> B means A (client) is a subclass of B (provider). Arrows (almost) always go from client to provider. (The only exceptions are in the case that arrows are used to represent data or control flow.)
(Why "incoming" and "outgoing" inheritance? Means nothing to me! I "inherit" from my grandfather; I don't have "incoming" or "outgoing" inheritance to him! ;-)
- on
On Feb 1, 2008, at 8:10, Tudor Girba wrote:
I = A -> B, I is the inheritance definition between A, B such that:
- I subclass = A
- I superclass = B
- A outgoingInheritance includes I,
- B incomingInheritance includes I.
I think the confusion is because we actually never used the incomingInheritance and outgoingInheritance, because these are derived, and before we only saved in MSE underived attributes. So, before we only counted on the subclass and superclass definitions, and they are the correct ones.
But in the latest version it is fixed.
Doru
On Feb 1, 2008, at 12:17 AM, Adrian Kuhn wrote:
I dont understand, is it as follows?
A superclass B subclass
cheers, AA
On 31 Jan 2008, at 21:20 , Tudor Girba wrote:
If A -> B, it should mean that
- A has an outgoingInheritance to B, and
- B has an incomingInheritance from A.
I fixed the descriptions now.
Doru
On Jan 31, 2008, at 7:38 PM, Adrian Kuhn wrote:
Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
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
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
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
We already have incoming/outgoing invocations, and incoming accesses. So, for naming consistency we thought of outgoing inheritances. In all these cases, the client has outgoing arrows and the client has incoming arrows.
The goal is to have a naming scheme that can be generalized. This also would help to add some more descriptive attributes, like "withinParent", so that you can form outgoingInvocationsWithinParent or something like that. Stef's group struggled quite a bit with these issues, and I think it would pay off to have a naming scheme that is more uniform.
Does it make more sense from this perspective?
Doru
On Feb 1, 2008, at 8:27 AM, Oscar Nierstrasz wrote:
If you are consistent with UML convention, then A -> B means A (client) is a subclass of B (provider). Arrows (almost) always go from client to provider. (The only exceptions are in the case that arrows are used to represent data or control flow.)
(Why "incoming" and "outgoing" inheritance? Means nothing to me! I "inherit" from my grandfather; I don't have "incoming" or "outgoing" inheritance to him! ;-)
- on
On Feb 1, 2008, at 8:10, Tudor Girba wrote:
I = A -> B, I is the inheritance definition between A, B such that:
- I subclass = A
- I superclass = B
- A outgoingInheritance includes I,
- B incomingInheritance includes I.
I think the confusion is because we actually never used the incomingInheritance and outgoingInheritance, because these are derived, and before we only saved in MSE underived attributes. So, before we only counted on the subclass and superclass definitions, and they are the correct ones.
But in the latest version it is fixed.
Doru
On Feb 1, 2008, at 12:17 AM, Adrian Kuhn wrote:
I dont understand, is it as follows?
A superclass B subclass
cheers, AA
On 31 Jan 2008, at 21:20 , Tudor Girba wrote:
If A -> B, it should mean that
- A has an outgoingInheritance to B, and
- B has an incomingInheritance from A.
I fixed the descriptions now.
Doru
On Jan 31, 2008, at 7:38 PM, Adrian Kuhn wrote:
Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
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
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
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
-- www.tudorgirba.com www.tudorgirba.com/blog
"It's not what we do that matters most, it's how we do it."
On Feb 1, 2008, at 8:38, Tudor Girba wrote:
We already have incoming/outgoing invocations, and incoming accesses. So, for naming consistency we thought of outgoing inheritances.
That makes no sense to me!
In all these cases, the client has outgoing arrows and the client has incoming arrows.
Say what?
- on
:)
Let's take the example again.
A -> B still means that "A superclasses" includes B and that "B subclasses" includes A.
But, we also have Inh = A -> B as an explicit reification for the inheritance definition so that "Inh subclass" = A and "Inh superclass" = B. Inh is an edge with an arrow that starts from A and points to B. So, A has an outgoing edge and B has an incoming edge. Hence "A outgoingInheritances" includes Inh, and "B incomingInheritances" includes Inh.
We will only use these "outgoing/incoming" selectors when we want to work with dependencies explicitly. For most use cases we only work with "subclasses" and "superclasses" of the classes.
How is it now?
Doru
On Feb 1, 2008, at 8:41 AM, Oscar Nierstrasz wrote:
On Feb 1, 2008, at 8:38, Tudor Girba wrote:
We already have incoming/outgoing invocations, and incoming accesses. So, for naming consistency we thought of outgoing inheritances.
That makes no sense to me!
In all these cases, the client has outgoing arrows and the client has incoming arrows.
Say what?
- on
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
"Every now and then stop and ask yourself if the war you're fighting is the right one."
On 1 Feb 2008, at 9:24 , Tudor Girba wrote:
A -> B still means that "A superclasses" includes B and that "B subclasses" includes A.
Correct notation is lower-than-colon!!!
A <: B
which means, A is a subtype of B. This is the standard notation in typing theory (Luca Cadelli, etc pp...) we should stick to that.
For the naming scheme, we should not take that to the ridiculous, it does not make any sense to label inheritances in- or outgoing. We should allow an exception of the rule there.
cheers, AA
Hi,
On Feb 1, 2008, at 10:18 AM, Adrian Kuhn wrote:
On 1 Feb 2008, at 9:24 , Tudor Girba wrote:
A -> B still means that "A superclasses" includes B and that "B subclasses" includes A.
Correct notation is lower-than-colon!!!
A <: B which means, A is a subtype of B. This is the standard notation in typing theory (Luca Cadelli, etc pp...) we should stick to that.
Well, A -> B is in UML and I thought that we are closer to UML than we are to typing theory. And until now we always took this view on the world. Of course, we can change it, but it has nothing to do with correctness.
For the naming scheme, we should not take that to the ridiculous, it does not make any sense to label inheritances in- or outgoing. We should allow an exception of the rule there.
So, what would then names be then? Just for the record, I have no preconceived ideas here.
Stef, it is exactly because of getting people confused that we said that in case of confusion draw the UML diagram and then you know what goes in and what gets out.
Doru
-- www.tudorgirba.com www.tudorgirba.com/blog
"We cannot reach the flow of things unless we let go."
Ok, so what would superclassDefinitions mean? Would it mean the inheritance definitions that point to the classes that I inherit from, or the inheritance definitions that have me as superclass? :)
I think that no matter what point of view is, we will be able to find another one that can induce confusion. For me incoming and outgoing works, but that is just because I remember with the convention.
That is why when we discussed about this (quite a long time ago) we said that if for invocations and accesses it is quite clear what incoming and outgoing means, then we can use the same for inheritance, just so that when people do not know they can always think that it is like in this other cases in which we have arrows.
Maybe we could name them inheritancesFromMySubclasses and inheritancesToMySuperclasses.
Doru
On Feb 1, 2008, at 1:54 PM, Stéphane Ducasse wrote:
Stef, it is exactly because of getting people confused that we said that in case of confusion draw the UML diagram and then you know what goes in and what gets out.
I know still superclassDefinitions and subclassDefinitions are easier for me to understand _______________________________________________ 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
"The coherence of a trip is given by the clearness of the goal."
Point subclass gives you the subclasses.
Point superclass does not give you the subclass.
Stef
On Feb 1, 2008, at 2:08 PM, Tudor Girba wrote:
Ok, so what would superclassDefinitions mean? Would it mean the inheritance definitions that point to the classes that I inherit from, or the inheritance definitions that have me as superclass? :)
I think that no matter what point of view is, we will be able to find another one that can induce confusion. For me incoming and outgoing works, but that is just because I remember with the convention.
That is why when we discussed about this (quite a long time ago) we said that if for invocations and accesses it is quite clear what incoming and outgoing means, then we can use the same for inheritance, just so that when people do not know they can always think that it is like in this other cases in which we have arrows.
Maybe we could name them inheritancesFromMySubclasses and inheritancesToMySuperclasses.
Doru
On Feb 1, 2008, at 1:54 PM, Stéphane Ducasse wrote:
Stef, it is exactly because of getting people confused that we said that in case of confusion draw the UML diagram and then you know what goes in and what gets out.
I know still superclassDefinitions and subclassDefinitions are easier for me to understand _______________________________________________ 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
"The coherence of a trip is given by the clearness of the goal."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
still superclassDefinitions and subclassDefinitions are easier for me to understand
+1
AA
Adrian Kuhn wrote:
On 1 Feb 2008, at 9:24 , Tudor Girba wrote:
A -> B still means that "A superclasses" includes B and that "B subclasses" includes A.
Correct notation is lower-than-colon!!!
A <: B
which means, A is a subtype of B. This is the standard notation in typing theory (Luca Cadelli, etc pp...) we should stick to that.
I don't agree with this. Types and subtypes are not necessarily linked to inheritance. Look at the typesystem of Cecil which is used totally decoupled from the inheritance hierarchies. Inheritance is -> like Doru says.
Me too. I said it in the past but as a kind of dyslecxic person I thought it was me :)
Stef
On Feb 1, 2008, at 8:27 AM, Oscar Nierstrasz wrote:
If you are consistent with UML convention, then A -> B means A (client) is a subclass of B (provider). Arrows (almost) always go from client to provider. (The only exceptions are in the case that arrows are used to represent data or control flow.)
(Why "incoming" and "outgoing" inheritance? Means nothing to me! I "inherit" from my grandfather; I don't have "incoming" or "outgoing" inheritance to him! ;-)
- on
On Feb 1, 2008, at 8:10, Tudor Girba wrote:
I = A -> B, I is the inheritance definition between A, B such that:
- I subclass = A
- I superclass = B
- A outgoingInheritance includes I,
- B incomingInheritance includes I.
I think the confusion is because we actually never used the incomingInheritance and outgoingInheritance, because these are derived, and before we only saved in MSE underived attributes. So, before we only counted on the subclass and superclass definitions, and they are the correct ones.
But in the latest version it is fixed.
Doru
On Feb 1, 2008, at 12:17 AM, Adrian Kuhn wrote:
I dont understand, is it as follows?
A superclass B subclass
cheers, AA
On 31 Jan 2008, at 21:20 , Tudor Girba wrote:
If A -> B, it should mean that
- A has an outgoingInheritance to B, and
- B has an incomingInheritance from A.
I fixed the descriptions now.
Doru
On Jan 31, 2008, at 7:38 PM, Adrian Kuhn wrote:
Which one is the superclass and which one the subclass? The current implementation of Moose seems to do the opposite of the Famix spec, so which one is right? ^^
AA
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
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
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
-
Adrian Kuhn -
Oscar Nierstrasz -
Stéphane Ducasse -
Toon Verwaest -
Tudor Girba