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 AAA21470; Tue, 2 Apr 2002 00:54:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 AAA21117 for ; Tue, 2 Apr 2002 00:54:55 +0200 (MET DST) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g31Msrf14997 for ; Tue, 2 Apr 2002 00:54:54 +0200 (MET DST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (2467 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 1 Apr 2002 14:54:49 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Date: Mon, 1 Apr 2002 14:54:33 -0800 Subject: Re: [Caml-list] let or val in objects Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Richard Nyberg , caml-list@inria.fr To: John Prevost From: james woodyatt In-Reply-To: <20020401042820.A74928@laurelin.dementia.org> Message-Id: <6ECAB092-45C3-11D6-8146-000502DB38F5@wetware.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Monday, April 1, 2002, at 01:28 AM, John Prevost wrote: > On Sun, Mar 31, 2002 at 10:40:51PM +0200, Richard Nyberg wrote: >> Hello, I'm a bit confused regarding let bindings and nonmutable vals in >> objects. Are there any difference between the classes a and b? or are >> they >> equivalent? >> >> Like this: >> >> class a fd = >> let is = in_channel_of_descr fd in object ... end >> >> class b fd = >> object val is = in_channel_of_descr fd ... end;; > > In the second case, "is" is a named value that's part of the > object--inheriting > classes can access its value, and if it is mutable, change the value. > > In the first case, "is" is a variable in the closure of the methods in > the object. Inheriting classes may not access its value in any way, > including > (of course) modifying it if it has a mutable component. I was following this thread in the hopes that I might learn whether there is any difference (in space or time) between values hidden by class signature matching and values in the methods closure. For example, I wanted to know if there is any substantial savings to be gained by choosing one of the following forms over the other: (* assume: type t val f: t -> unit *) (* 1 *) class foo (x : t) = object method bar = f x end (* 2 *) class type foo_t = object method bar: unit end class foo x : foo_t = object val x' = x method bar = f x' end As far as I can tell, these two forms are semantically equivalent. So, I looked to see if the compiler generates the same output code for each case. Cursory examination of the output of ocamlopt -S on my Mac OS X unit seems to show that it does. I suspect the second case is optimized into the first case. Or something. -- j h woodyatt ------------------- 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