Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass

[Jeff Schultz <jws@cs.mu.OZ.AU>]

> 1) Implementing multiple interfaces.
> 
> In Java, things sometimes get awkward if you want to work with values
> that implement multiple interfaces at once:
> 
> class MyThingy implements Colored, HasPoint {
>     ...
> }
> 
> Okay, so the difficulty in this set of classes and interfaces (which
> *has* actually bitten me in the wild fairly frequently) is that there
> is no way to declare a variable as "any object that is of both type
> Colored and type HasPoint."  If we do this:
> 
> interface ColoredHasPoint extends Colored, HasPoint { ... }
> 
> then MyThingy is not an instance of ColoredHasPoint.  It has all of
> the appropriate methods, but it was not *declared* to have this type. 
> Therefore, it does not have the correct type.  So you end up having to
> write:
> 
>     void useColoredHasPoint(Object o) {
>         Colored c = (Colored) o;
>         HasPoint h = (HasPoint) o;
>         ... = c.getColor();
>         ... = h.getPoint();
>     }
> 
> and obviously the system has now broken down.  AS long as you work
> with only one interface at a time, you're in fine shape.  As soon as
> you need more than one and have no other requirements, you're in
> trouble.  In O'Caml, of course, the above is trivial:
> 
>     let use_colored_has_point o =
>        let color = o#get_color () in
>        let point = o#get_point () in
>        ...

True enough, but I think of this as more to do with the convenience
provided by type inference's creation of names for types the
programmer didn't write.  So the type of use_colored_has_point is
something like

    < get_color : unit -> 'a; get_point : unit -> 'b; .. > -> ...

where type inference has come up with a new type that the programmer
could have written, but didn't have to.

One can get the same effect with Java 1.5's poor man's generics by
writing

    <T extends Colored & HasPoint> void useColoredHasPoint2(T o) {
        Color color = o.getColor();
	Point point = o.getPoint();
    }

so even though it's verbose, it's certainly possible.  (If it also had
typedef, it might not be all that bad.)

Of course, just because an object has both get_color and get_point, or
implements both Colored and HasPoint interfaces, doesn't mean that the
colour and point returned have any specific relationship to each
other, so it's not a given that mixing them on any arbitrary object
makes sense.  To be safe, one needs some way to check that they do go
together, perhaps a ColoredPoint interface or the discipline of saying
that this getPoint method is here because this object implements
HasPoint, and obeys HasPoint's contract with the programmer, whatever
that is, isn't always such a bad thing :-)


    Jeff Schultz

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners