Browse thread
Smells like duck-typing
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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