Browse thread
Instance variables can't be polymorphic?
-
Zheng Li
-
Jacques Garrigue
-
Zheng Li
- Goswin von Brederlow
-
Zheng Li
-
Jacques Garrigue
[
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: | 2009-04-06 (09:55) |
From: | Goswin von Brederlow <goswin-v-b@w...> |
Subject: | Re: [Caml-list] Re: Instance variables can't be polymorphic? {a few more annoyances on "val" syntax} |
Zheng Li <zheng_li@users.sourceforge.net> writes: > [OT]: Here are a few more annoyances on the syntax of instance > variable I've encountered. I recorded it here for comments: > > Why it can't just copy the common "let" syntax in OCaml? Even though > it's possible to just lift the awkward "val" definitions out of > objects and using "let" instead, I'm really uncomfortable when being > forced to do that. Besides, the lifted variables won't be accessible > through inheritance any more, so they are not strictly equivalent or > interchangeable in semantics. > > Currently, the "val" syntax > > - doesn't support pattern matching assignment. Instead of > -- > let a,b,c,d = tuple4 > -- > one write > -- > val a = match tuple4 with a,_,_,_ -> a > val b = match tuple4 with _,b,_,_ -> b > val c = match tuple4 with _,_,c,_ -> c > val d = match tuple4 with _,_,_,d -> d > -- > This is still the easy case, image if your pattern matching will > also trigger some side-effect. class foo = let (a,b,c,d) = tuple4 in object val a = a val b = b val c = c val d = d end > - doesn't support sharing state. > -- > let up,down = > let r = ref 0 in > (fun () -> incr r; !r), > (fun () -> decr r; !r) > -- > can't be expressed directly as instance variables Same thing. Use let to create the shared state and then assign in the object. Although that really ought to be written as class foo : object (* to hide count if you really want that *) method private up : unit method private down : unit end = object val count = ref 0 method private up = incr count method private down = decr count end > - doesn't support shortcut syntax of function definition like > -- > val f x y z = x + y + z > -- > instead one must write > -- > val f = fun x y z -> x + y + z > -- same > - doesn't support recursion. Instead of > -- > val rec fact n = > if n <= 1 then 1 else n * fact (n-1) > -- > one must write > -- > val fact = > let rec fact_rec n = > if n <= 1 then 1 else n * fact_rec (n-1) in > fact_rec > -- same > - all parallel assignments, no assignment orders, hence can't refer to > previous assignment > > -- > val x = 3 > val y = x + 11 > -- > > is wrong, even if it makes perfect sense in many situations. To access > "x", one is simply forced to declare "y" as method! same again. > Any comments? Yes, ocaml objects can drive one nuts. :) You seem to want to use classes with static functions (functions that do not have/use self). Why not use records? Is that just because you can not coerce record to a "subtype"? Sometimes one can use modules and functors instead of objects. MfG Goswin