From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA08848 for caml-redistribution; Fri, 18 Jun 1999 17:39:36 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA30696 for ; Fri, 18 Jun 1999 03:22:10 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id DAA18807 for ; Fri, 18 Jun 1999 03:22:06 +0200 (MET DST) Received: from localhost (safran.kurims.kyoto-u.ac.jp [130.54.16.91]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.7W) with ESMTP id KAA06312; Fri, 18 Jun 1999 10:18:36 +0900 (JST) To: fessant@pa.dec.com Cc: caml-list@inria.fr Subject: Re: Objects contrib: new URL ... In-Reply-To: Your message of "Thu, 17 Jun 1999 10:16:32 -0700 (PDT)" <14185.11632.214915.820706@virtualc5.pa.dec.com> References: <14185.11632.214915.820706@virtualc5.pa.dec.com> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990618101902C.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 18 Jun 1999 10:19:02 +0900 From: Jacques GARRIGUE X-Dispatcher: imput version 980905(IM100) Content-Transfer-Encoding: 7bit Sender: weis From: Fabrice Le Fessant > In our case, the "cast" construct for the object-oriented programing > style can be compared to the "ref" or the "array" types for the > imperative programming style. Both can lead to "unsafe" programs > (should the compiler allow "x.(-1)" in a program as it currently does?), > but they can still be useful when used carefully. In that way, I trust > Ocaml users (demagogy :)). Agreed for array indices. Looks like a "needed evil" since the only way to avoid it would be dependent types (still, some people work at it). I don't see what is the problem with refs? This is an impure feature, but not dangerous in terms of type safety. And of course there are also exceptions, which are pretty bad when used the wrong way. > With this patch, I tried to increase the expressiveness of the language, > without breaking its safety. In this way, I think it is still better > than using Obj.magic, since the "implements" checks whether the types > can correctly be coerced. I agree that this is better than Obj.magic. However it lets people program in a JAVA-like style, quitting safe parametric polymorphism (i.e. parametric classes) for unsafe dynamic type checking. With your patch one can define collection classes without parameter, put anything inside them, and downcast to get the contents, like one does in JAVA. The problem is that lots of people come to caml from a world where casts are the standard way to obtain polymorphism. If you provide it with an easy syntax, they will not bother to learn about the benefits of parametric polymorphism (anti-demagogy :)). So I weaken my statement: casts are not an absolute evil which should not be allowed at all, but at least they should be hard to use, enough to encourage people to choose other methods when possible. > > Remark: > > You can already implement something similar inside the language: > > Can you really use an object (mutable) as the key in the hashtbl (its > hash value may change when it is modified ?) ? Objects have a unique oid, which is used for comparisons and hashing. Cf. byterun/hash.c. I must admit that your approach is more efficient, since you just have to check the pointer to the class. But again perfection may be a bad thing for an unsafe feature... Regards, Jacques P.S. Thanks for your path-to-the-patch.