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 LAA31358; Thu, 12 Jul 2001 11:37:35 +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 LAA31454 for ; Thu, 12 Jul 2001 11:37:34 +0200 (MET DST) Received: from chopin.ai.univie.ac.at (chopin.ai.univie.ac.at [131.130.174.170]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6C9bWn26102 for ; Thu, 12 Jul 2001 11:37:32 +0200 (MET DST) Received: (from markus@localhost) by chopin.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id LAA05593; Thu, 12 Jul 2001 11:37:29 +0200 Date: Thu, 12 Jul 2001 11:37:29 +0200 From: Markus Mottl To: "Krishnaswami, Neel" Cc: caml-list@inria.fr Subject: Re: [Caml-list] A G'Caml question" + additional info Message-ID: <20010712113729.B5381@chopin.ai.univie.ac.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from neelk@cswcasa.com on Wed, Jul 11, 2001 at 18:23:04 -0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 11 Jul 2001, Krishnaswami, Neel wrote: > For instance, I recently wrote yet another set implementation, because > the functorial interface to the Set module in the standard library > wouldn't let me use it in a fully polymorphic fashion. This is a shortcoming of the standard library that there are no polymorphic implementations of "Set" and similar. It's very easy to extract a polymorphic (module-) version from the existing code. Note that the non-polymorphic version also has advantages for users: e.g. they don't have to pass around comparison functions all the time. > If the Set library had been written using OCaml's object system, > then I would not have had to redo my own. I disagree: a lot of important functionality cannot be easily replicated with objects alone - at least not in a reasonable way. Just imagine using the "map" function on an object version of "Map": The type system won't allow you to implement this function in its full generality within the class. If you implement it outside with a normal function, you either have to use very inefficient add-operations or have to reveal the datastructure (breaks interfaces) or you have to do a tricky module/class combination (function sees internals, module hides representation using abstract types), which immediately eliminates the benefits of objects (you'd have to use an abstract type anyway rather than operate on object types). > From this experience I conclude that the right thing is to use the > features that offer the nicest degree of modularity and reusability. Right. That's why I almost exclusively prefer modules over objects... ;) Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr