From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 2BE14BC6B for ; Thu, 28 Jun 2007 03:13:12 +0200 (CEST) Received: from stirner.roentgeninstitut.de (stirner.roentgeninstitut.de [212.110.109.210]) by concorde.inria.fr (8.13.6/8.13.6) with SMTP id l5S1DBMm012790 for ; Thu, 28 Jun 2007 03:13:11 +0200 Received: (qmail 23805 invoked by uid 1000); 27 Jun 2007 18:13:11 -0700 Date: Wed, 27 Jun 2007 18:13:11 -0700 From: Christian Stork To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Execution time of class versus record Message-ID: <20070628011311.GA23556@stirner.roentgeninstitut.de> Mail-Followup-To: caml-list@yquem.inria.fr References: <467E8A6E.9050700@menta.net> <200706250425.28516.jon@ffconsultancy.com> <467FA3F8.2030601@lix.polytechnique.fr> <200706251307.16487.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706251307.16487.jon@ffconsultancy.com> X-Archive: encrypt User-Agent: Mutt/1.5.13 (2006-08-11) X-Miltered: at concorde with ID 46830B27.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 invocation:01 struct:01 foo:01 struct:01 foo:01 namespaces:01 namespaces:01 syntax:01 semantics:01 clashes:01 gal:98 806:98 021:98 wrote:01 On Mon, Jun 25, 2007 at 01:07:16PM +0100, Jon Harrop wrote: ... > I was referring to virtual function dispatch and not the explicit invocation > of a particular member. > > Consider this example: > > module A = struct > let foo = object method f n = n+1 end > end;; > module B = struct > let bar = object method f n = n+2 end > end;; > > let apply o = o#f;; > > apply A.foo 0;; > apply B.bar 0;; > > If modules imposed separate namespaces then the objects in the modules A and B > could not be related, so you could not use them for dispatch in this way > (probably a very common use of objects as well). Actually, treating methods much like types wrt module namespaces is a very sensible idea. Without going into further detail of the syntax, in the above example, module A might declare the method A.f and if module B intends to implement a method with same semantics as A.f it could be written as module B = struct let bar = object method A.f n = n+2 end end;; and let apply o = o#A.f would work just the same. This scheme avoids unintended name clashes, increases modularity, and, I think, it could result in a more efficient implementation. Unfortunately, I'd expect that programmers would react very adversly to this unexpected additional notational burden. So there would be a need to alleviate that burden somehow. In the literature the above idea is sometimes called "stand-alone messages". See Peter Froehlich's work on Lagoona[1] for more information. -Chris [1]: Peter H. Froehlich, Andreas Gal, and Michael Franz. Supporting Software Composition at the Programming-Language Level. Science of Computer Programming, Special Issue on New Software Composition Concepts. Volume 56, Numbers 1-2, Pages 41-57, April 2005. -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F