From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: weis
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA19179 for caml-redistribution; Thu, 4 Nov 1999 19:50:31 +0100 (MET)
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 AAA19926 for <caml-list@pauillac.inria.fr>; Thu, 4 Nov 1999 00:19:17 +0100 (MET)
Received: from mail20.svr.pol.co.uk (mail20.svr.pol.co.uk [195.92.193.218])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id AAA28011
	for <caml-list@inria.fr>; Thu, 4 Nov 1999 00:19:16 +0100 (MET)
Received: from [195.92.197.25] (helo=mail17.svr.pol.co.uk)
	by mail20.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11j9gN-0007LR-00; Wed, 3 Nov 1999 23:19:11 +0000
Received: from modem-86.vanity.dialup.pol.co.uk ([62.136.103.86] helo=toy.william.bogus)
	by mail17.svr.pol.co.uk with esmtp (Exim 2.12 #2)
	id 11j9dj-0007LA-00; Wed, 3 Nov 1999 23:16:28 +0000
Received: (from williamc@localhost)
	by toy.william.bogus (8.8.7/8.8.7) id XAA17986;
	Wed, 3 Nov 1999 23:13:07 GMT
Date: Wed, 3 Nov 1999 23:13:07 GMT
Message-Id: <199911032313.XAA17986@toy.william.bogus>
From: William Chesters <williamc@dai.ed.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Mark Engelberg" <mark.engelberg@bigfoot.com>
Cc: <caml-list@inria.fr>
Subject: Classes AND Modules?  What's the point?
In-Reply-To: <00fb01bf2447$9ef382a0$03dedede@walldata.com>
References: <00fb01bf2447$9ef382a0$03dedede@walldata.com>
X-Mailer: VM 6.34 under Emacs 20.2.1
Sender: weis

Mark Engelberg writes:
 > The thing that confuses me the most about OCaml is that there is a huge
 > overlap between the functionality of classes and modules, with a couple of
 > subtle differences.

   Interestingly, the big difference is that modules are not "first
class values".  You can't pass the whole thing around, along with its
dispatch table, like you can an object.  You can't write

	module type Shape = sig
	  val area: unit -> float
	end

	module Square (Init: sig val side: float end) = struct
	  let side = Init.side
	  let area () = side *. side
	end

	let foo M = M.area ()     (* this isn't allowed *)

	let _ =
	  let module It = Square (struct let side = 50. end)
	  in
	  foo It                  (* nor is this *)

So although you can create modules on the fly with "let module", and
pass their _members_ around, you can't really use the instantiations
conveniently as objects.  There is no way to use modules per se to
achieve class-style polymorphism.

   I have often thought that you could get something very like the
ocaml class system, with similar semantics and implementational
issues, by this kind of route.

 > The problem is that because modules are slightly more powerful, it appears
 > that the entire standard library is implemented as modules, not classes,
 > despite the fact that this is supposed to be Object-oriented Caml!

   IIRC OLabl ships with object versions of some of the libraries.

   Don't forget that object a method invocation is a little slower
than a module function call---I measured fetches from a Hashtbl,
indirected through an object wrapper, about 10% slower than fetches
indirected through a module.  Anyway, object-using programs don't
always necessarily work out prettier than module-based ones.