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: | Dario Teixeira <darioteixeira@y...> |
| Subject: | Re: [Caml-list] Smells like duck-typing |
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