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=1.0 required=5.0 tests=AWL,MSGID_MULTIPLE_AT autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id C9988BBAF for ; Sun, 31 May 2009 09:34:40 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuECAD7QIUpRZ90wkWdsb2JhbACYFQEBAQEJCwoHEQO1KIQMBQ X-IronPort-AV: E=Sophos;i="4.41,278,1241388000"; d="scan'208";a="28598247" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail3-smtp-sop.national.inria.fr with ESMTP; 31 May 2009 09:34:40 +0200 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090531073439.ODYB6611.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Sun, 31 May 2009 08:34:39 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090531073439.SPUT2093.aamtaout03-winn.ispmail.ntl.com@romulus.metastack.com>; Sun, 31 May 2009 08:34:39 +0100 Received: from COUNTERTENOR (genkt-048-065.t-mobile.co.uk.254.149.in-addr.arpa [149.254.48.65] (may be forged)) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id n4V7YWfi013600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 31 May 2009 08:34:35 +0100 From: "David Allsopp" To: "'Dave Benjamin'" , "'Dario Teixeira'" Cc: References: <380372.47429.qm@web111503.mail.gq1.yahoo.com> <4A22132E.30505@ramenlabs.com> In-Reply-To: <4A22132E.30505@ramenlabs.com> Subject: RE: [Caml-list] Width subtyping Date: Sun, 31 May 2009 08:34:29 +0100 Message-ID: <00e101c9e1c2$3e501330$baf03990$@allsopp@metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnhr1GFtl4GOkuBQb+l8RMbN7tP6gACed3Q Content-Language: en-gb Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.0 c=1 a=fGLC1evsdqcl60vqy_0A:9 a=_85DHLFOEDcNQCZpczMA:7 a=57RPsYwUY3I1Y5J-AstDQlnSSUIA:4 X-Spam: no; 0.00; subtyping:01 translating:01 syntax:01 runtime:01 variants:01 polymorphic:01 wrote:01 syntactic:01 caml-list:01 functions:01 functions:01 oop:01 variant:02 width:97 match:02 > Dario Teixeira wrote: > > You are right. I was probably too fixated on the OOP way of doing = this, > > translating record fields into object fields and the functions = acting on > > records into object methods. Your solution, where record fields = become object > > methods and external functions act on objects that match a certain = structure, > > does solve the inconveniences I mentioned before. But objects are = still > > a somewhat heavier solution, right? >=20 > Heavier in terms of efficiency, or syntax? My concern is the former. The extra two fields per "record" and the = heavier runtime calls make them so systemically slower that (to me, at = least) it just feels "wrong" to use objects just to achieve a little = syntactic clarity and a small reduction in the amount of code written. = Polymorphic variants (which use only slightly more memory than regular = variant values) otherwise perform at the same speed as their normal = counterparts. David