comp.lang.ada
 help / color / mirror / Atom feed
From: Graham Perkins <gperkins@dmu.ac.uk>
Subject: Re: covariance and parameter modes (was: Re: Instantiating Generic Object)
Date: 1997/11/14
Date: 1997-11-14T00:00:00+00:00	[thread overview]
Message-ID: <346C65D1.5C7E@dmu.ac.uk> (raw)
In-Reply-To: 346B1E1F.25F3@hello.confusion.nl

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]


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

contravariant in-parameter for type safety.  But it aint
semantically safe, eg sqrt(-3)

contravariant "out" result not safe, but it could well
make more sense for programmer who doesn't want
his functions creating mixed-mode arithmetic.

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!

My point is this: foolproof type safety of any language feature
often has to be obtained at the cost of some expressive power.
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.

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

It's a trade-off and there obviously isn't one correct
answer.

---------

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.

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.

---------

  [Roger, was that a good disguise of my cow, herbivore,
   food, grass, example that we all got heartily sick of? ]




  reply	other threads:[~1997-11-14  0:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <646g1b$avs@solaria.cc.gatech.edu>
     [not found] ` <3466EBB8.61AE@stratus.com>
     [not found]   ` <EJFy23.47o@ecf.toronto.edu>
     [not found]     ` <slrn66f65r.f80.kennel@lyapunov.ucsd.edu>
     [not found]       ` <EJHnM4.H97@ecf.toronto.edu>
     [not found]         ` <3468E43B.7BCFFF2C@munich.netsurf.de>
1997-11-13  0:00           ` covariance and parameter modes (was: Re: Instantiating Generic Object) Karel Th�nissen
1997-11-14  0:00             ` Graham Perkins [this message]
1997-11-18  0:00               ` Karel Th�nissen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox