Re: Co-/Contravariance (was: mandatory newbie musing)

[Norbert Nemec]

After all, that's a conceptual problem in the modelling process: In 
fact, $RATIONAL cannot be a subtype of $INTEGER. It should rather be the 
other way around, since "subtype" is a kind of an equivalent to 
"subset". $INTEGER being a subtype of $RATIONAL would mean: I can use 
an $INTEGER everytime a $RATIONAL is needed. And that really is true. 
Of course, after a division, I might not get a $INTEGER as result, but 
that's another matter.

In fact, $INTEGER does even have additional properties like a possible
    next: SAME is ... end;
method.

The one essential property of groups and fields - how is it called in 
English? "closedness" would be the translation from German - simply 
cannot be modelled without genericity. In subtyping, meaning the look 
at only a subset of the original, the "closedness" simply is lost, and 
has to be "defined" newly. Correctly it would have to be:

class $GROUP{T} ...

class $FIELD{T} < $GROUP{T} ...

class $RATIONAL < $FIELD{$RATIONAL} ...

class $INTEGER < $RATIONAL, $GROUP{$INTEGER} ...

Of course, now you have $INTEGER < $FIELD{$RATIONAL}, but that simply 
sais: integers are a sub*set* of the field of rationals, which is fully 
correct.



On Tue, Oct 03, 2000 at 08:59:19PM +0000, Matt Kennel wrote:
> The modeling problem is usually with parallel hierarchies, when you
> have two classes that mutually interact (e.g. by methods of one taking
> arguments of type of the other), and 'logically' it makes sense to
> have simultaneous descendents of both.
> 
> Think of the moral equivalent of a commutation diagram in mathematics.   
> 
>           A   ...   X
>           |         |
>           B   ...   Y
> 
> B descends from A and Y descends from X, but the '...' relation (not
> an inheritance or subtyping relation but something not defined in the
> language but in the cognitive problem space) stays analogous from A to
> X as it does from B to Y.
> 
> This is when non-static-typesafe covariance is useful, or more
> correctly, when a better language idea is indicated.
> 
> 
> The solutionhack with genericity would be something like
> 
>         A
>         |   
>        A{*} 
>         |
>        B{*}
> 
>        A{X}   ...   X
> 
>        B{Y}   ...   Y
> 
> 
> for instance, let A be "GROUP",  A{*} be GROUP{T < GROUP_ELEMENT} and
> B{*} be FIELD{T < FIELD_ELEMENT},   with methods like  add(arg:T):T. 
> 
> X being INTEGERS and Y being RATIONALS
> 
> As I went from programming Sather first to Eiffel second, I also
> thought that argument covariance was a silly idea and would lead to trouble.
> As I have used Eiffel I've decided it's only a half-silly idea {but
> with an essential core of silliness remaining} and hasn't ever lead me to
> trouble. 

-- 
-- ______________________________________________________
-- JESUS CHRIST IS LORD!
--          To Him, even that machine here has to obey...
--
-- _________________________________Norbert "Nobbi" Nemec
-- Hindenburgstr. 44  ...  D-91054 Erlangen  ...  Germany
-- eMail: <address@hidden>   Tel: +49-(0)-9131-204180