From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 53DFF7FB38 for ; Sat, 27 Dec 2014 00:45:24 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.192.178; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jordojw@gmail.com designates 209.85.192.178 as permitted sender) identity=mailfrom; client-ip=209.85.192.178; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pd0-f178.google.com) identity=helo; client-ip=209.85.192.178; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-pd0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUAANvxnVTRVcCym2dsb2JhbABbhDDMXwKBCRYBAQEBAREBAQEBAQYLCwkULoQMAQEBAwESKAYBGxAKAwEDAQsGBQsNLiMRAQUBHAYTIod1AQMJCAWoDz4xjRmCd4pZChknDVSENQEBAQEBAQEBAQEBAQEBAQEBAQEBAREBBQ6PESUzB4MWgRMFiUuFOIgFggeDfYoCNYEVhDFOgQOBQAEBAQ X-IPAS-Result: AnUAANvxnVTRVcCym2dsb2JhbABbhDDMXwKBCRYBAQEBAREBAQEBAQYLCwkULoQMAQEBAwESKAYBGxAKAwEDAQsGBQsNLiMRAQUBHAYTIod1AQMJCAWoDz4xjRmCd4pZChknDVSENQEBAQEBAQEBAQEBAQEBAQEBAQEBAREBBQ6PESUzB4MWgRMFiUuFOIgFggeDfYoCNYEVhDFOgQOBQAEBAQ X-IronPort-AV: E=Sophos;i="5.07,649,1413237600"; d="scan'208";a="94770506" Received: from mail-pd0-f178.google.com ([209.85.192.178]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Dec 2014 00:45:23 +0100 Received: by mail-pd0-f178.google.com with SMTP id r10so13572486pdi.23 for ; Fri, 26 Dec 2014 15:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4x3VS2phEulu8B/Q9M1866SFDzW/SzmVTziv/WbnLWg=; b=Ff5onTkcLOIbiYyaIy+YnHr0Sss7RhF/8TTKhQRMD/ac/BmvQqVQya1w2ShNs23/5p c0iEnXaEkVa7mEdujAden9RVBr4Dbdy/AbcVuNMEuWwnj6EkLpZkd/FmoNNPdwDdIgYX J3gRTXrF3lfItabWNtbHdcndhpj2MIt5t6F5P6iXm31hGPE30p97ARpdG9LYDF+9JF4N aKLtf6YVoGofJhHv+OLxeZBr73NV0q5fafIuHgnWJ3tDOvXwGXMhspjr+UQITNW2p512 Gxt0sqOMWUNJ9Ztpm0rEiBhr3T1pP/ut8k95UQOnagDcAYs8OyAu08ibUY0CupBXMh5r tdaA== X-Received: by 10.70.88.231 with SMTP id bj7mr70673805pdb.168.1419637521689; Fri, 26 Dec 2014 15:45:21 -0800 (PST) Received: from [10.110.192.8] (mobile-166-171-250-210.mycingular.net. [166.171.250.210]) by mx.google.com with ESMTPSA id m7sm29206984pdj.47.2014.12.26.15.45.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Dec 2014 15:45:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jordo X-Mailer: iPhone Mail (12B436) In-Reply-To: <547C3E49.7030809@frisch.fr> Date: Fri, 26 Dec 2014 15:45:21 -0800 Cc: Gerd Stolpmann , "caml-list@inria.fr" Content-Transfer-Encoding: quoted-printable Message-Id: <0435EEFC-C65E-47EF-95BA-573ED7856D52@gmail.com> References: <1417362565.6436.88.camel@e130.lan.sumadev.de> <547C3E49.7030809@frisch.fr> To: Alain Frisch X-Validation-by: jordanjcw@gmail.com Subject: Re: [Caml-list] Object Features Yes, this is primarily what I'm looking to do. The only question I have is = whether or not the type annotation is required. Ideally, it would not be. T= his, along with some basic pattern matching ability would allow objects to = be treated as a lightweight structurally subtyped records. Even if the use = of "self" is limited or prohibited, I would still find tremendous use for t= hem. OCaml objects are already so close to fulfilling this role, aside from= these relatively small features. The presence of more advanced class featu= res needn't add friction to using objects as more flexible records (at leas= t that's the hope). Have you taken a look at SuccessorML's extensible records? Also, Elm's reco= rds work in similar ways to what I'm describing (pattern matching and exten= sion without requiring annotation). I've seen many new languages gain tract= ion recently, many of them treating records as extensible, pattern matched = and structurally subtyped. I realized that OCaml may have had something ver= y close for a long time, but is missing a little bit of polish. Sent from my iPhone > On Dec 1, 2014, at 2:09 AM, Alain Frisch wrote: >=20 >> On 11/30/2014 04:49 PM, Gerd Stolpmann wrote: >> What could in deed be useful is a more light-weight construction that >> layers objects, i.e. you define a new object around an existing one: >=20 > Indeed, being able to define an object by extending an existing one would= be quite useful (perhaps overriding some methods, being understood that th= is doesn't affect late-bound calls from that object to itself). >=20 > I'd rather see that as a new kind of class expressions, say "of object ", where could be an object expression (with a fixed type) > so that you could write: >=20 > let new_object old_object =3D > object > inherit of object (old_object : t) >=20 > method foo =3D ... >=20 > method! bar =3D ... > end >=20 > This would also allow to merge two existing objects into one. >=20 > If has type < m1:t1; ...; mn: tn >, "of object " would be eq= uivalent to >=20 > let o =3D in > object > method m1 =3D o # m1 > ... > method mn =3D o # mn > end >=20 >=20 >=20 > -- Alain