From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA20570; Sun, 14 Jul 2002 05:32:58 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA20501 for ; Sun, 14 Jul 2002 05:32:57 +0200 (MET DST) Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6E3QRf29091 for ; Sun, 14 Jul 2002 05:26:31 +0200 (MET DST) Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17]) by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id MAA10736; Sun, 14 Jul 2002 12:26:06 +0900 To: oleg_inconnu@myrealbox.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Five Questions about Objects In-Reply-To: <200207131340.JAA07158@hickory.cc.columbia.edu> References: <200207131340.JAA07158@hickory.cc.columbia.edu> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020714122600U.garrigue@kurims.kyoto-u.ac.jp> Date: Sun, 14 Jul 2002 12:26:00 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Oleg > A few questions on objects: > > 1) Why does the following code define a polymorphic class > > class point a b = > object > val x = a > val y = b > end;; It is not a "polymorphic class", but a class containing polymorphic variables. You have no way to access them from outside the class. > but adding "method get () = (x, y)" results in type errors only > resolvable by specifying types with "class ['a, 'b] point (a:'a) > (b:'b)" ? Why doesn't > > class point a b = > object > val x = a > val y = b > method get () = (x, y) > end;; > > give me a polymorphic class? A class definition defines four things * a class value, to build objects and inherit from * a class type, to use in interfaces * an object type, to abbreviate the < m1: t1; ...; mn: tn > notation * an object subtype #c, to abbreviate < m1: t1; ...; mn: tn; .. > The above would be ok for the class value alone, but in order to define the class and object types, you need to make explicit the type parameters. This is the goal of the class ['a] c ... notation. Otherwise you might end up with type definition different from what you were expecting (two many type variables, different parameter order...) I sometimes wonder if it would not be possible to allow defining the class alone, without defining types, but this might be more confusing than useful. > 2) What is the point of "class" and "new" keywords? How are they better than > "let" ? E.g. > > let point a b = > object > val x = a > val y = b > method get () = (x, y) > end;; See the above explanation. A class definition does not define only a value. > let my_point = point 3 7;; No very deep reason for new, yet there are some semantic differences. For instance, if your class takes no arguments but contains mutable fields, each call to new creates a fresh object. That is, let c = new c in c, c is not equivalent to new c, new c > 3) Is it possible to access object datafields directly or only through > methods? Only through methods. Otherwise variables should appear in the object type. > 4) Can I construct an object that the following function f would accept? > # let f a = a#m1 (); a#b#m2 ();; > val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a = Yoriyuki Yamagata already answered. The LablGTK is full of such methods calls. > 5) What is the current state of marshalling objects? Is Jacques's > patch going to be used in the upcoming O'Caml version or is it too > untested? Not in the upcoming version, but maybe in the next. The semantics are a bit tricky, and we don't want to put possibly wrong code in the official distribution. A known issue is the interaction with dynamic loading. In most cases it should be ok, but one can imagine bad scenarii. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners