Browse thread
Bug? Constraints get ignored in methods
[
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: | Jacques Garrigue <garrigue@m...> |
| Subject: | Re: [Caml-list] Bug? Constraints get ignored in methods |
From: Goswin von Brederlow <goswin-v-b@web.de>
> > If you really want to stick to methods only (because of library
> > design, for instance), then a clever trick is to use a coercion
> > methods:
> >
> > class virtual base_type =
> > object (self)
> > val mutable virtual next : base_type option
>
> Why is next virtual here? Doesn't that require that anyone inheriting
> base_type has to define their own version of next? Seems like needless
> duplication.
No real reason. Just that you class type contained such field, so I
pasted it it the least effecting way. But since no method inside
base_type accesses it, I agree that it seems better not to put it
there.
> > method virtual set_next_base : base_type option -> unit
> > method as_base = (self :> base_type)
> > method set_next : 'a. <as_base : base_type; ..> as 'a -> unit =
> > fun x -> self#set_next_base x#as_base
> > end
A small typo in the above. Like in the function example it should be
fun x -> self#set_next_base (Some x#as_base)
> This helps a lot. Nice little trick to go through an immediate object
> type.
Actually, the self coercion and the use of a non-abbreviated object
type are independent, but in general it is too heavy to use the second
without the first.
Jacques Garrigue