* Re: covariance and parameter modes (was: Re: Instantiating Generic Object)
1997-11-14 0:00 ` Graham Perkins
@ 1997-11-18 0:00 ` Karel Th�nissen
0 siblings, 0 replies; 3+ messages in thread
From: Karel Th�nissen @ 1997-11-18 0:00 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5651 bytes --]
Graham Perkins wrote:
>
> Karel Th�nissen wrote:
> > For in-parameters, contravariance is the typesafe approach. For
> > out-parameters, and hence function results, covariance is the typesafe
> > approach. For in-out-parameters, being a combination of the two, only
> > 'invariance' is typesafe.
>
> ancestor--> whole_sqrt( n:NATURAL ) : NATURAL
> descendant--> whole_sqrt( n:INTEGER ) : INTEGER
What are these classes INTEGER and NATURAL? Are they part of Eiffel? I
couldn't find them in the index of OOSC-2. From syntax, the example
certainly isn't Ada.
So I assume that NATURAL and INTEGER are taken from mathematics and
stand for {0, 1, 2, 3, .....} ('N') and {...., -3, -2, -1, 0, 1, 2, 3,
...} ('Z') respectively. Mathematically, N is a subset of Z, and in OO,
NATURAL is a subtype INTEGER with a strengthened invariant.
So either your ancestors and descendants are mixed up, or I didn't fully
understand you :-).
> contravariant in-parameter for type safety. But it aint
Your example uses a covariant in-parameter and a covariant
out-parameter, as both change with their classes from NATURAL to
INTEGER.
> semantically safe, eg sqrt(-3)
But neither was the ancestor, if the ancestor and the decendant hadn't
been mixed up.
> contravariant "out" result not safe, but it could well
> make more sense for programmer who doesn't want
> his functions creating mixed-mode arithmetic.
I do not like the idea that typesafety should be traded for this
convenience.
> DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER
> this may not be a good example, please let's not go
> down a long thread about how dreadful I am at designing
> numerical libraries!
Accepted.
> My point is this: foolproof type safety of any language feature
> often has to be obtained at the cost of some expressive power.
Quite possible indeed.
> In some casess it may be better to take a more pragmatic approach
> and let programmers do things that make sense in terms of the
> domain they are working with.
Okay. But why allow the programmer to silently mess up the typing
system, push the compiler into system-wide inference mode, and create
code where the bugs creep out at the next round of redesign or
maintenance? Why not have typesafety by default and deviations when
explicitly indicated by the programmer?
Making sense in terms of the problem domain sounds good, but that
presupposes 1) a good understanding of the problem domain, 2) a good
understanding of OO, and 3) a good understanding of how to map from OO
to the problem domain. The latter is the thing that really worries me if
I read OO-literature. Okay, I am a semanticist by profession/education,
I confess. Now execute me 8-).
> Eiffel's covariance originally gave high flexibility and
> created horrible (but solvable) validity problem. New
> CAT rules restrict it a little and make validity much
> simpler (class rather than system level).
Sorry, but I think it is a mess. Fortunately enough for Eiffel, most
languages do even worse. Eiffel goes at great length with DBC, weakening
preconditions, strengthening postconditions and invariants, so for me
this CAT-talk is a Fremdk�rper.
> It's a trade-off and there obviously isn't one correct
> answer.
I doubt that.
> For domain argument concerning parameter/result variance,
> simply think of an object with local container and exported
> "put" and "get" methods. You put something into the object,
> or you take it out.
Do I hear a cow eating grass and producing milk here?
> Now if you allow variance at all, a descendant object
> should allow you to put and get something else. Should the
> "something else" be a descendant or ancestor of "something"?
> I don't care. Whichever rule you make, you end up
> having the *same* variance policy for in-parameters
> and out-results.
Correct, so in this example we would like to have interface inheritance
and possibly implementation inheritance, but not type inheritance (and
thus loose LSP).
[Going back to COWs and ANIMALs, because it is less abstract:] It is
useful to have ANIMALs eating FOOD in genernal and to have the
descendant COWs eating GRASS in particular. So the convariant
in-parameter breaks the typesafety rules. This now can indicate an error
in our design of COW: it should eat any food not just grass, or it can
indicate that COW is not a _subtype_ of ANIMAL. Your choice. If you
chose the latter, you loose the ability the pass a cow as a parameter to
a routine that assumes an ANIMAL, because the routine may start feeding
the cow with any food, including MICE and RATS.
Now people may at first wonder when they arrive at the conclusion that
COW should not be a subtype of ANIMAL. But this paradox stems from the
fact that most people are semantically confused about OO and even
propose OO as a formalism to describe 'the 'world'.
If we look very carefully at what we wrote in our specification of
ANIMAL, then it says that ANIMALs eat any FOOD. So if that is the
definition of ANIMAL, then COWs are definitely not ANIMALs, because they
will not eat _any_ FOOD. However, with our contrived mapping of
semantics and formal semantics we read the specification of ANIMALs so
that they eat _some_kind_of_ FOOD, which it doesn't say.
> [Roger, was that a good disguise of my cow, herbivore,
> food, grass, example that we all got heartily sick of? ]
8-) yes, with permission
--
Groeten, Karel Th�nissen
-- mijn e-adres is versleuteld om junk-mailers op het net te verwarren
-- verwijder confusion om zo mijn echte adres te verkrijgen
-- my e-mail address is scrambled to confuse spammers
-- remove the confusion to obtain my true address
^ permalink raw reply [flat|nested] 3+ messages in thread