Re: [Caml-list] Smells like duck-typing

[Dario Teixeira <darioteixeira@yahoo.com>]

Hi,

(This is a collective reply to all the issues that were raised by my
previous message; sorry if I don't answer each message individually).

I made the early "reverse inheritance" suggestion somewhat facetiously,
but judging from the replies, there was a certain amount of confusion
about what I meant.

I'll try to describe what I have in mind.  I'll do it by modelling
the problem in an imaginary OCaml-derived language that features
"reverse inheritance".  Please read on:


The "story" class is one that is fully defined.  Think of it as a raw
block of marble from which the non-important pieces can be carved out.
To avoid confusion, let's call a class of this kind a "marble-class":

marble-class story (id, title, intro, body) =
object
	method id: int = id
	method title: string = title
	method intro: string = intro
	method body: string = body
end

Now, a "full_story" is one that is also fully defined.  Taking as starting
point the "story" block-class previously defined, you don't need to carve
out anything to obtain a full_story:

marble-class full_story (id, title, intro, body) =
object
	carves story (id, title, intro, body)
end


However, a "blurb_story" does introduce changes: it can be formed by
taking the original story as a starting point, and removing the "body"
chunk of marble.  Note that I am using some new keywords: carves, removes,
and CARVED:

marble-class blurb_story (id, title, intro) =
object
	carves story (id, title, intro, CARVED)
	removes method body
end


Similarly, a "fresh_story" is a story without the "id" field:

marble-class fresh_story (title, intro, body)
object
	carves story (CARVED, title, intro, body)
	removes method id
end


Now, if you think in terms of traditional inheritance, a blurb_story
"B" is also a story "A", and so on (with OCaml's subtyping inheritance,
the semantics are a bit different, but let's not go there right now).
Therefore you would expect that any method that works on A should also
work on B.  But here it's precisely the opposite: anything that works on
B should also work on A, but not the other way around.  If the confusion
is purely linguistic, then let's not call it "reverse inheritance";
let's use "marble carving" instead.  (Note that for these semantics
to be correct, then a carved-class is not allowed to add new methods,
but only to remove existing methods from the class it is carving).

Finally the big question: is this useful or even feasible to implement?
Probably not.  But for the problem I have at hand, this is still the
modelling that best fits my mental picture of the relation between the
various story types.

Cheers,
Dario



      ___________________________________________________________ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html