Dario Teixeira wrote:

>>So now you've defined full_story, blurb_story, and fresh_story as 
>>types.  Now, I write:
>>
>>let get_body (story: full_story) = story#get_body;;
>>let my_blurb = new blurb_story(id, "A Title", "An Intro");;
>>let my_body = get_body my_blurb;;
>>
>>what happens?
>>    
>>
>
>Hi,
>
>Well, that's only a problem if you insist in thinking in terms
>of inheritance.  Remember that the semantics of marble-carving
>are NOT "all that works on full_story should also work on blurb_story",
>but the other way around.
>
>  
>
So all full stories are also blurbs, but blurbs are not full stories.  
So full stories are a more specific type than blurbs are, because while 
we can always use a full story as a blurb, we can't use a blurb as a 
full story.

>Also, imagine you were to add the "get_body" method to the root
>"story" class.  The type system in Marble-Caml is smart enough
>to tell you that since the blurb_story carved out the "body" field,
>then it must also carve out methods that use it.  Aren't imaginary
>languages wonderfull?... :-)
>
>  
>
It's much easier, rather than detecting when things have to be removed, 
to simply detect when things can be added.  Every "remove members" 
relationship can be expressed as an "add members" relationship going the 
other direction.  Start with the simpler (fewer members) type and then 
create the derived type by adding members to make the more complex (more 
members) type.  Anything you can do with one direction of deriving types 
you can do with the other direction of deriving.

Which is why Robert said you had just reinvented inheritance.

>(In addition, note that in any real world situation, it wouldn't
>make any sense for the user to want to invoke get_body on a blurb
>object -- after all, by definition blurbs have no body).
>  
>
Yep.

Brian