31 Jan
2008
31 Jan
'08
7:38 p.m.
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
31 Jan
31 Jan
9:20 p.m.
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(a)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."
1 Feb
1 Feb
12:17 a.m.
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:10 a.m.
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Value is always contextual."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
8:27 a.m.
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:
--
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 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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:38 a.m.
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"It's not what we do that matters most, it's how we do it."
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I dont understand, is it as follows?
A superclass
B subclass
cheers,
AA
On 31 Jan 2008, at 21:20 , Tudor Girba 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 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(a)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(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:41 a.m.
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
9:24 a.m.
:)
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:
--
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."
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:18 a.m.
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
11:08 a.m.
Hi,
On Feb 1, 2008, at 10:18 AM, Adrian Kuhn wrote:
On 1 Feb 2008, at 9:24 , Tudor Girba wrote:
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.
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.
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."
2:08 p.m.
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:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"The coherence of a trip is given by the clearness of the goal."
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
3:27 p.m.
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:
--
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:31 p.m.
still superclassDefinitions and subclassDefinitions
are easier for me
to understand
+1
AA
--
Adrian Kuhn MSc
http://www.iam.unibe.ch/~akuhn/news.xml (RSS)
2 Feb
2 Feb
9:54 p.m.
New subject: Incoming- and outgoing inheritance, can some please explain!?
Adrian Kuhn wrote:
On 1 Feb 2008, at 9:24 , Tudor Girba wrote:
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.
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.
1 Feb
1 Feb
10:48 a.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I dont understand, is it as follows?
A superclass
B subclass
cheers,
AA
On 31 Jan 2008, at 21:20 , Tudor Girba 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 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(a)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(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
6213
days inactive
6215
days old
15 comments
5 participants
participants (5)
-
Adrian Kuhn -
Oscar Nierstrasz -
Stéphane Ducasse -
Toon Verwaest -
Tudor Girba