From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 63995BC29 for ; Tue, 29 Aug 2006 14:03:48 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7TC3i16009842 for ; Tue, 29 Aug 2006 14:03:48 +0200 Received: from [84.58.144.101] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GI2JZ0upJ-0005iX; Tue, 29 Aug 2006 14:03:35 +0200 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id E2DFCC08C; Tue, 29 Aug 2006 14:03:32 +0200 (CEST) Subject: Re: [Caml-list] Class/prototype-based OO From: Gerd Stolpmann To: Ted Kremenek Cc: skaller , david.baelde@ens-lyon.org, Ocaml In-Reply-To: References: <53c655920608250051x48d81cbagabf8039f0269beee@mail.gmail.com> <1156505490.20759.354.camel@rosella.wigram> Content-Type: text/plain Date: Tue, 29 Aug 2006 14:03:26 +0200 Message-Id: <1156853008.21883.84.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at concorde with ID 44F42D20.00A by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 ocaml:01 ocaml:01 lacks:01 downcasts:01 run-time:01 rtti:01 run-time:01 rtti:01 o'caml:01 downcasts:01 parametric:01 polymorphism:01 variants:01 Am Montag, den 28.08.2006, 20:11 -0700 schrieb Ted Kremenek: > On Aug 25, 2006, at 4:31 AM, skaller wrote: > > > Thus, from a software engineering viewpoint, nominal typing > > is not a viable option .. which is one reason programming > > in Java or C++ using OO sucks. > > > > In Ocaml, it works much better because you can actually > > write algorithms which work with many different types, > > provided only they support the 'right methods'. > > While the structural typing in Ocaml is wonderful (I really love it), > there are missing features of the OO system in OCaml that can be > particularly bothersome, and are worth considering when comparing the > OO features of Ocaml with other languages (including those that use > nominal typing). That sounds a bit like as if the OO language with more features was the better one. The problem is that certain features are incompatible with each other, at least in a practical sense, i.e. you cannot have good and efficient implementations for all. > For example, from what I can tell it appears that Ocaml lacks real > support for "downcasts" in the language, which require run-time type > information (RTTI) and run-time checks. In theory, RTTI is possible in O'Caml. But it is very costly: Object types are complex structures and not only names. So any downcast would be a very expensive operation (a full type check). > In the context of structural > typing, I am talking about "casting" an object with a type with a > given set of method signatures to another type with an extended set > of method signatures. Whether or not you agree downcasts are a good > thing, it is one thing to take into account when comparing the OO > features of different languages (and this is a feature that both C++ > and Java have that OCaml does not). In general, I don't believe the > OO system in Ocaml supports any kind of RTTI, which enables features > such as downcasts and reflection. All of the type checking of > objects in OCaml is static, which is very nice but often insufficient. Please note that OCaml is not only OO, so if you observe that you need downcasts often, you probably have an inappropriate programming style. For example, if you want to have a user-extensible data structure, you normally implement it with modules and parametric polymorphism. If the user of this structure wants to store different things into the same structure, one can define a variant type. (Well, I know that OO enthusiasts have a lot of prejudices against variants, mostly because they never saw which role variants can play in a polymorphism-rich language.) > Actually, if I am wrong about this I would be very happy if someone > out there can point this out. Certainly one can implement downcasts > using Obj.magic and some hand-crafted RTTI, but that is obviously not > a desired solution. Certainly not this way. Simply use exceptions for home-made RTTI: class type foo = ... exception Foo of foo class foo_class : foo = object(self) ... method downcast = raise(Foo(self : #foo :> foo)) end let downcast_foo (obj : < downcast : unit; ..>) = try obj # downcast with Foo x -> x | _ -> failwith "This is not a foo!" Although this is restricted to monomorphic types please note that the other languages you mention only have this sort of types. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------