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."