Version française
Home     About     Download     Resources     Contact us    
Browse thread
Smells like duck-typing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Smells like duck-typing

On Thu, 2007-10-18 at 18:49 +0200, Arnaud Spiwack wrote:
> skaller wrote :
> > The soundness theory is simple: methods have to be covariant,
> > but mutators have to be contravariant, and since mutators
> > are also method they have to be *invariant*, and invariance
> > effectively means an OO  class cannot have subtypes.
> >   
> You got that part wrong. I means that subtypes have the same types for 
> the same methods (not subtypes, exactly the same types), but it can be 
> extended with extra methods (you can be slighlty looser using 
> specialisation of the self-type). That's how things work.

I don't think so but I may have misunderstood: 
the problem is, you're thinking of values
again. With a value subtype, the extra invariant adds extra
structure which can admit new interesting theorems, so 
you can add new methods to calculate them.

But that never happens with mutators because you cannot
HAVE any additional invariants. The derived type has
to have exactly the same set of values as the base,
in which case you cannot have any new interesting
methods -- any method you have can always be defined
in terms of the characteristic methods already in
the base (assuming the whole public state is accessible
of course).

Note I am simplifying since real objects are a mix
of mutable and immutable state, in that case
of course you can subtype the immutable state and leave
the mutable state invariant. But that's just factorisation
which complicates the argument.

>From that view point there is actually only ONE possible
mutator: assignment (since, you can always construct the
new state in a new object and assign it, there is no need
for any partial mutators). For example for a mutable
complex number you do not need 'set_real(), set_imaginary()'
mutators, you only need a constructor Cart(r,i) plus assignment.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net