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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 03E83800BE for ; Fri, 10 Feb 2017 15:40:40 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=zhenya1007@gmail.com; spf=Pass smtp.mailfrom=zhenya1007@gmail.com; spf=None smtp.helo=postmaster@mail-yw0-f176.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of zhenya1007@gmail.com) identity=pra; client-ip=209.85.161.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="zhenya1007@gmail.com"; x-sender="zhenya1007@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of zhenya1007@gmail.com designates 209.85.161.176 as permitted sender) identity=mailfrom; client-ip=209.85.161.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="zhenya1007@gmail.com"; x-sender="zhenya1007@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-yw0-f176.google.com) identity=helo; client-ip=209.85.161.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="zhenya1007@gmail.com"; x-sender="postmaster@mail-yw0-f176.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AKg8W2xPytH9BGycIm3ol6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0K/T9rarrMEGX3/hxlliBBdydsKMYzbqJ+P67ESxYuNDa7yBEKMQNHzY+yu?= =?us-ascii?q?wo3CUYSPafDkP6KPO4JwcbJ+9lEGFfwnegLEJOE9z/bVCB6le77DoVBwmtfVEt?= =?us-ascii?q?fre9ScbuiJGT2uf6xJ3SfwgA0D6wZpt2NArs8EPXu9VA0qV4LaNk5wXGr31ZM9?= =?us-ascii?q?5R2GlpI1mTgxv94I/k7p5u9TVZ4qp5qOZPVKz7e+IzSrkOX2duCHw8+MC+7UqL?= =?us-ascii?q?dgCI/HZJCmg=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAACiz51Yf7ChVdFeGwEBAQMBAQEJA?= =?us-ascii?q?QEBFwEBBAEBCgEBgkSBOQsxWAeDUpppAQEBBoEijR+CZoc+JoV8AoJvB0IVAQE?= =?us-ascii?q?BAQEBAQEBAQESAQEJCwsKGzGCMxmCHQEBAQMBIwQZARQHHQEDAQsGAwILDRULC?= =?us-ascii?q?gICIQEBEQEFARwGEwmJVgEDCAUIDpIGkQ0/jAKBaxgFARyDCQWDXgoZJw1Vgzk?= =?us-ascii?q?BAQEBBgEBAQEBAQEZAgYShXaFM4JRgg8zgkeCXwWBKwEBAYdehzWKdyEPCAEBg?= =?us-ascii?q?TgJhnCBXoNsA4QWkQWKNYcZFB6BFTWBIE9RF0qDKioPHYF/IjUBih0BAQE?= X-IPAS-Result: =?us-ascii?q?A0CdAACiz51Yf7ChVdFeGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?BgkSBOQsxWAeDUpppAQEBBoEijR+CZoc+JoV8AoJvB0IVAQEBAQEBAQEBAQESA?= =?us-ascii?q?QEJCwsKGzGCMxmCHQEBAQMBIwQZARQHHQEDAQsGAwILDRULCgICIQEBEQEFARw?= =?us-ascii?q?GEwmJVgEDCAUIDpIGkQ0/jAKBaxgFARyDCQWDXgoZJw1VgzkBAQEBBgEBAQEBA?= =?us-ascii?q?QEZAgYShXaFM4JRgg8zgkeCXwWBKwEBAYdehzWKdyEPCAEBgTgJhnCBXoNsA4Q?= =?us-ascii?q?WkQWKNYcZFB6BFTWBIE9RF0qDKioPHYF/IjUBih0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,141,1484002800"; d="scan'208,217";a="259761600" Received: from mail-yw0-f176.google.com ([209.85.161.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 10 Feb 2017 15:40:38 +0100 Received: by mail-yw0-f176.google.com with SMTP id w75so22067721ywg.1 for ; Fri, 10 Feb 2017 06:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UF5n/wfZPx990/VrwwDw2ZTJ+BO5YNdXJOmQZaZWNIg=; b=E30NaUx+UOa3QaHnakh7/WlM0jx63geakAZaGAXlIy0hRx2UOdveIDbksrArulZk7V HdoXZ6FPsrGggRwQf7NKyluOG4WUk00UmloRydVJ5K2lPL2P62EMjBUUrMXsMAtG2kuI tfoCDc0JG2/nCdRF6xUKF+D16xJeLmCnjzUJgEsusUfYMMvBhxxFtkSujVVtUkXzr8IU xuTOvQaKcW/NcOAvKBGTqGW/43F4KS6IcoiWH9fmwMIsrfpCbvR+KYnIyu76GH/IaEZ8 9v9xfK1c7cq5iWPeoTZbJlPPiI7UZZKP4nJejo2yoKesxC8jo23+ntE/rcYhCxHMznG9 44Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UF5n/wfZPx990/VrwwDw2ZTJ+BO5YNdXJOmQZaZWNIg=; b=Jql3JVTfqaviLsuDCBMTH/6IWx/KACW1JX0JQhu9c02lQ5Iao6tmb1G3OPP1Ni9qYY 9pM2zbhSw0PucuoOUdECQvRHg8HnCdkDtmzQUR7pwroFw+zI7hKHqbFAe7HNHILGCG22 v48weBXJA5aoil94SpaKkboRuZYbBzjS16eGz6WVLb9zh7PNvuw0izlx37c7z0xTKgeO kDPgn6Q3FAbi220pE26zY4VlxSS4irKhn+D8kYU5tkoCyo8U3Tb04ipEss3Zn9ef6e8B Tk1vF8CLXF/ilYk45Thuu9QmKiD3YOZ5oAhsf9MDH0/mmdsazsjOLO3GYsev3VOddu9T UuKQ== X-Gm-Message-State: AMke39n6f55Xho4BjIJ/7gUM4AHOll0kaBKRSfhr7qryNZb0s+yGuV5LjpsVCvz9gm0d/AHgNkPMA3rt4yWkRw== X-Received: by 10.129.124.84 with SMTP id x81mr7348650ywc.224.1486737636850; Fri, 10 Feb 2017 06:40:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.40 with HTTP; Fri, 10 Feb 2017 06:40:36 -0800 (PST) In-Reply-To: <1486719507.2806603.876599584.3796D567@webmail.messagingengine.com> References: <1486683451.12698.83.camel@gerd-stolpmann.de> <1486719507.2806603.876599584.3796D567@webmail.messagingengine.com> From: Evgeny Roubinchtein Date: Fri, 10 Feb 2017 09:40:36 -0500 Message-ID: To: Leo White Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001a11494168b80aba05482e14bd Subject: Re: [Caml-list] namespace inside object? --001a11494168b80aba05482e14bd Content-Type: text/plain; charset=UTF-8 Apologies in advance for my ignorance, but is there some reference(s) you could point me to where the notion of "open recursion" is defined? I am pretty sure I understand "dynamic dispatch." -- Best, Zhenya On Fri, Feb 10, 2017 at 4:38 AM, Leo White wrote: > I think it would be more correct to say that you want open recursion. > Classes are the easiest way to get that in OCaml, and they indeed use > dynamic dispatch and inheritance, but there are other mechanisms that > provide open recursion. For example, most proposals for "mixin modules" > support open recursion but I wouldn't say they use dynamic dispatch. > > Regards, > > Leo > > On Thu, 9 Feb 2017, at 10:16 PM, Steffen Smolka wrote: > > Right....but you have to explicitly make that choice when you implement > `f`. With objects on the other hand, somebody may write a base > implementation c: > > class c = object(this) > method foo = ... this#bar ... > method bar = ... this#foo ... (* original definition *) > end > > Later on, somebody else may refine this implementation by overwriting > c#bar: > > class c2 = object(this) > inherit c > method bar = ... (* new definition *) > end > > Now c2#foo will invoke the new definition of bar, even though the author > of `c` may have never anticipated this (and did not have to account for > this possibility when he defined foo). > > So, I would say "dynamic dispatch" plus inheritance give you the ability > to extend modules in ways that weren't necessarily anticipated by the > original author of the module. And yet all the code written by the original > author will work with your extended version of the module. > > -- Steffen > > > > On Thu, Feb 9, 2017 at 9:01 PM, Yaron Minsky > wrote: > > I've always been a bit confused about what the term "dynamic dispatch" > means, but don't first class modules provide what you want? After all, > when you write: > > let f (module M : S) x = > M.g x > > the specific function M.g is determined dynamically, depending on > which first class module is passed into f. > > y > > On Thu, Feb 9, 2017 at 6:54 PM, Steffen Smolka > wrote: > > Yeah, I have seen that there is support for first class modules, that's > > pretty cool stuff! > > I do need dynamic dispatch, though. > > > > -- Steffen > > > > On Thu, Feb 9, 2017 at 6:37 PM, Gerd Stolpmann > > wrote: > >> > >> Am Donnerstag, den 09.02.2017, 18:19 -0500 schrieb Steffen Smolka: > >> > >> Thanks for the detailed answer, Jeremy! > >> > >> If you're keen to stick with objects > >> > >> > >> Yes, I rely on inheritance and dynamic dispatch for what I have in mind. > >> (This is actually the first time I'm touching the dark object oriented > side > >> of OCaml :) ) > >> > >> To give some more context, I am refactoring some code that uses modules > >> and no objects. The reason I want to move to objects is that I want to > >> derive a slightly enhanced module from some base implementation. > Inheritance > >> + dynamic dispatch allow me to do so with very little trouble: I can > simply > >> overwrite a few methods from the base implementation. > >> > >> I suppose I could achieve the same by turning the base module into a > >> functor, and abstracting over the functions that my enhanced > implementation > >> needs to replace. I think it won't be quite as natural, but I'll give > that a > >> try. > >> > >> > >> First-class modules could also be an option: Let's assume both the base > >> module and the modified one can use the same module type: > >> > >> module T = sig ... end > >> > >> Now, define the base module like > >> > >> module Base : T = > >> ... > >> end > >> > >> then, define the modified one: > >> > >> module Mod : T = > >> include Base > >> ... now override what you need to change but note that there's no > >> dynamic dispatch ... > >> end > >> > >> Of course, you could also use functors for making these modules. > >> > >> Now turn this into first-class modules and pass them around: > >> > >> let base = (module Base : T) > >> let mod = (module Mod : T) > >> > >> The syntax for unpacking the module is quite cumbersome: > >> > >> let module M = (val base : T) in > >> M.function ... > >> > >> Unfortunately, there's nothing simple like base.function. > >> > >> Compared with objects you get: > >> > >> You can also put types and (to some degree) modules into these "code > >> containers" > >> However, there's no dynamic dispatch except you arrange explicitly for > >> that, e.g. with references to functions > >> Generally, a heavier syntax, but it might be ok > >> > >> > >> Gerd > >> > >> > >> > >> Or you could select the encoding using a variant type: > >> > >> > >> Good idea, and I'm happy with the syntax for the caller. But I'm more > >> concerned with the organization of the code; this would mix the Latin1 > and > >> Utf8 implementations. I would rather keep them separate. > >> > >> -- Steffen > >> > >> > >> On Thu, Feb 9, 2017 at 5:55 PM, Jeremy Yallop wrote: > >> > >> Dear Steffen, > >> > >> On 9 February 2017 at 20:36, Steffen Smolka > wrote: > >> > Is it possible to create namespaces inside an object? Concretely, I > >> > would > >> > like to write > >> > > >> > class buffer = object(self) > >> > ... > >> > method get = ... > >> > > >> > module Latin1 = struct > >> > method get = ... > >> > end > >> > > >> > module Utf8 = struct > >> > method get = ... > >> > end > >> > end > >> > > >> > so that given an object b : buffer, I can call methods > >> > b#get > >> > b#Latin1.get > >> > b#Utf8.get > >> > >> It's possible to achieve something like this using methods that return > >> objects. If your nested objects don't need to access the internal > >> state of the parent then you might write it like this: > >> > >> class buffer = > >> let latin1 = object > >> method get = ... > >> end > >> and utf8 = object > >> method get = ... > >> end in > >> object(self) > >> ... > >> method get = ... > >> method latin1 = latin1 > >> method utf8 = utf8 > >> end > >> > >> With this approach you can write > >> > >> b#get > >> b#latin1#get > >> b#utf8#get > >> > >> which, apart from some minor orthographic differences, looks like what > >> you were aiming for. > >> > >> Your intuition that this isn't really idiomatic OCaml is right, > >> though. In OCaml, unlike some other languages with classes and > >> objects, classes are not usually used as namespaces; method names are > >> globally (or, rather, "ambiently") scoped, and there's no real support > >> for the kind of nesting that you're interested in. Instead, people > >> typically build nested namespaces using modules: > >> > >> module Buffer = > >> struct > >> let get = ... > >> > >> module Latin1 = struct > >> let get = ... > >> end > >> > >> module Utf8 = struct > >> let get = ... > >> end > >> end > >> > >> With the module approach you write the 'receiver' after the 'method' > >> rather than before, but that doesn't seem like a huge hardship. (10% > >> of the world manages to get by with VSO languages.) > >> > >> Buffer.get b ... > >> Buffer.Latin1.get b ... > >> Buffer.Utf8.get b ... > >> > >> If you're keen to stick with objects there are slightly more idiomatic > >> ways to make it work. You could, of course, replace the '.' with a > >> '_' and define methods 'latin1_get', 'utf8_get' in place of > >> 'Latin1.get', 'Utf8.get'. Or you could select the encoding using a > >> variant type: > >> > >> type enc = Latin1 | Utf8 > >> > >> class buffer = > >> object (self) > >> method get = function > >> | Latin1 -> ... > >> | Utf8 -> ... > >> end > >> > >> Of course, the order of the words in an invocation changes again, but > >> there's no real increase in complexity for the caller: > >> > >> b#get Latin1 > >> b#get Utf8 > >> > >> This last approach can be taken quite far -- for example, you could > >> enrich the type 'enc' so that the return type of 'get' varies > >> according to the encoding. > >> > >> Kind regards, > >> > >> Jeremy > >> > >> > >> -- > >> ------------------------------------------------------------ > >> Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > >> My OCaml site: http://www.camlcity.org > >> Contact details: http://www.camlcity.org/contact.html > >> Company homepage: http://www.gerd-stolpmann.de > >> ------------------------------------------------------------ > >> > > > > > --001a11494168b80aba05482e14bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies in advance for my ignorance, but is th= ere some reference(s) you could point me to where the notion of "open = recursion" is defined?=C2=A0 I am pretty sure I understand "dynam= ic dispatch."

--
Best,
Zhenya

On Fri, Feb 10, 2017 a= t 4:38 AM, Leo White <leo@lpw25.net> wrote:
I think it would be more corre= ct to say that you want open recursion. Classes are the easiest way to get = that in OCaml, and they indeed use dynamic dispatch and inheritance, but th= ere are other mechanisms that provide open recursion. For example, most pro= posals for "mixin modules" support open recursion but I wouldn= 9;t say they use dynamic dispatch.

Regards,

Leo
=

On Thu, 9 Feb 2017, at 10:16 PM, Steffen Smolka wrote:
Right....but you have to ex= plicitly make that choice when you implement `f`. With objects on the other= hand, somebody may write a base implementation c:

class c =3D object(this)
=C2=A0 method foo =3D ... this#bar ...
=C2=A0 method bar =3D ... this#foo ... =C2=A0(* original definition *)=
end

Later on, somebody else may refine this implementation by overwriting = c#bar:

class c2 =3D object(this)
=C2=A0 inherit c
=C2=A0 method bar =3D ... (* new definition *)
end

Now c2#foo will invoke the new definition of bar, even though the auth= or of `c` may have never anticipated this (and did not have to account for = this possibility when he defined foo).

So, I would say "dynamic dispatch" plus inheritance give you= the ability to extend modules in ways that weren't necessarily anticip= ated by the original author of the module. And yet all the code written by = the original author will work with your extended version of the module.
=

-- Steffen



On Thu, Feb 9, 2017 at 9:01 PM, Yaron Minsky &l= t;yminsky@janes= treet.com> wrote:
I've always been a bit confu= sed about what the term "dynamic dispatch"
means, but don't first class modules provide what you want? After= all,
when you write:

let f (module M : S) x =3D
=C2=A0 =C2=A0 M.g x

the specific function M.g is determined dynamically, depending on
=
which first class module is passed into f.

y

On Thu, Feb 9, 2017 at 6:54 PM, Steffen Smolka <smolka@cs.cornell.edu> wrote= :
> Yeah, I have seen that there is support for first class modules,= that's
> pretty cool stuff!
> I do need dynamic dispatch, though.
>
> -- Steffen
>
> On Thu, Feb 9, 2017 at 6:37 PM, Gerd Stolpmann <info@gerd-stolpmann.de&g= t;
> wrote:
>>
>> Am Donnerstag, den 09.02.2017, 18:19 -0500 schrieb Steffen S= molka:
>>
>> Thanks for the detailed answer, Jeremy!
>>
>> If you're keen to stick with objects
>>
>>
>> Yes, I rely on inheritance and dynamic dispatch for what I h= ave in mind.
>> (This is actually the first time I'm touching the dark o= bject oriented side
>> of OCaml :) )
>>
>> To give some more context, I am refactoring some code that u= ses modules
>> and no objects. The reason I want to move to objects is that= I want to
>> derive a slightly enhanced module from some base implementat= ion. Inheritance
>> + dynamic dispatch allow me to do so with very little troubl= e: I can simply
>> overwrite a few methods from the base implementation.
>>
>> I suppose I could achieve the same by turning the base modul= e into a
>> functor, and abstracting over the functions that my enhanced= implementation
>> needs to replace. I think it won't be quite as natural, = but I'll give that a
>> try.
>>
>>
>> First-class modules could also be an option:=C2=A0 Let's= assume both the base
>> module and the modified one can use the same module type:
>>
>> module T =3D sig ... end
>>
>> Now, define the base module like
>>
>> module Base : T =3D
>>=C2=A0 =C2=A0 ...
>> end
>>
>> then, define the modified one:
>>
>> module Mod : T =3D
>>=C2=A0 =C2=A0 include Base
>>=C2=A0 =C2=A0 ... now override what you need to change but no= te that there's no
>> dynamic dispatch ...
>> end
>>
>> Of course, you could also use functors for making these modu= les.
>>
>> Now turn this into first-class modules and pass them around:=
>>
>> let base =3D (module Base : T)
>> let mod =3D (module Mod : T)
>>
>> The syntax for unpacking the module is quite cumbersome:
=
>>
>> let module M =3D (val base : T) in
>> M.function ...
>>
>> Unfortunately, there's nothing simple like base.function= .
>>
>> Compared with objects you get:
>>
>> You can also put types and (to some degree) modules into the= se "code
>> containers"
>> However, there's no dynamic dispatch except you arrange = explicitly for
>> that, e.g. with references to functions
>> Generally, a heavier syntax, but it might be ok
>>
>>
>> Gerd
>>
>>
>>
>> Or you could select the encoding using a variant type:
>>
>>
>> Good idea, and I'm happy with the syntax for the caller.= But I'm more
>> concerned with the organization of the code; this would mix = the Latin1 and
>> Utf8 implementations. I would rather keep them separate.
=
>>
>> -- Steffen
>>
>>
>> On Thu, Feb 9, 2017 at 5:55 PM, Jeremy Yallop <yallop@gmail.com> wrote:=
>>
>> Dear Steffen,
>>
>> On 9 February 2017 at 20:36, Steffen Smolka <smolka@cs.cornell.edu>= ; wrote:
>> > Is it possible to create namespaces inside an object? C= oncretely, I
>> > would
>> > like to write
>> >
>> > class buffer =3D object(self)
>> >=C2=A0 =C2=A0...
>> >=C2=A0 =C2=A0method get =3D ...
>> >
>> >=C2=A0 =C2=A0module Latin1 =3D struct
>> >=C2=A0 =C2=A0 =C2=A0method get =3D ...
>> >=C2=A0 =C2=A0end
>> >
>> >=C2=A0 =C2=A0module Utf8 =3D struct
>> >=C2=A0 =C2=A0 =C2=A0method get =3D ...
>> >=C2=A0 =C2=A0end
>> > end
>> >
>> > so that given an object b : buffer, I can call methods<= br>
>> > b#get
>> > b#Latin1.get
>> > b#Utf8.get
>>
>> It's possible to achieve something like this using metho= ds that return
>> objects.=C2=A0 If your nested objects don't need to acce= ss the internal
>> state of the parent then you might write it like this:
>>
>>=C2=A0 =C2=A0class buffer =3D
>>=C2=A0 =C2=A0 =C2=A0let latin1 =3D object
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0method get =3D ...
>>=C2=A0 =C2=A0 end
>>=C2=A0 =C2=A0 and utf8 =3D object
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0method get =3D ...
>>=C2=A0 =C2=A0 end in
>>=C2=A0 =C2=A0 object(self)
>>=C2=A0 =C2=A0 =C2=A0 ...
>>=C2=A0 =C2=A0 =C2=A0 method get =3D ...
>>=C2=A0 =C2=A0 =C2=A0 method latin1 =3D latin1
>>=C2=A0 =C2=A0 =C2=A0 method utf8 =3D utf8
>>=C2=A0 =C2=A0 end
>>
>> With this approach you can write
>>
>>=C2=A0 =C2=A0 b#get
>>=C2=A0 =C2=A0 b#latin1#get
>>=C2=A0 =C2=A0 b#utf8#get
>>
>> which, apart from some minor orthographic differences, looks= like what
>> you were aiming for.
>>
>> Your intuition that this isn't really idiomatic OCaml is= right,
>> though.=C2=A0 In OCaml, unlike some other languages with cla= sses and
>> objects, classes are not usually used as namespaces; method = names are
>> globally (or, rather, "ambiently") scoped, and the= re's no real support
>> for the kind of nesting that you're interested in.=C2=A0= Instead, people
>> typically build nested namespaces using modules:
>>
>>=C2=A0 =C2=A0module Buffer =3D
>>=C2=A0 =C2=A0struct
>>=C2=A0 =C2=A0 =C2=A0 let get =3D ...
>>
>>=C2=A0 =C2=A0 =C2=A0 module Latin1 =3D struct
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0let get =3D ...
>>=C2=A0 =C2=A0 =C2=A0 end
>>
>>=C2=A0 =C2=A0 =C2=A0 module Utf8 =3D struct
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0let get =3D ...
>>=C2=A0 =C2=A0 =C2=A0 end
>>=C2=A0 =C2=A0end
>>
>> With the module approach you write the 'receiver' af= ter the 'method'
>> rather than before, but that doesn't seem like a huge ha= rdship.=C2=A0 (10%
>> of the world manages to get by with VSO languages.)
>>
>>=C2=A0 =C2=A0Buffer.get b ...
>>=C2=A0 =C2=A0Buffer.Latin1.get b ...
>>=C2=A0 =C2=A0Buffer.Utf8.get b ...
>>
>> If you're keen to stick with objects there are slightly = more idiomatic
>> ways to make it work.=C2=A0 You could, of course, replace th= e '.' with a
>> '_' and define methods 'latin1_get', 'ut= f8_get' in place of
>> 'Latin1.get', 'Utf8.get'.=C2=A0 Or you could= select the encoding using a
>> variant type:
>>
>>=C2=A0 =C2=A0type enc =3D Latin1 | Utf8
>>
>>=C2=A0 =C2=A0class buffer =3D
>>=C2=A0 =C2=A0object (self)
>>=C2=A0 =C2=A0 =C2=A0 method get =3D function
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Latin1 -> ...
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Utf8 -> ...
>>=C2=A0 =C2=A0end
>>
>> Of course, the order of the words in an invocation changes a= gain, but
>> there's no real increase in complexity for the caller:
>>
>>=C2=A0 =C2=A0b#get Latin1
>>=C2=A0 =C2=A0b#get Utf8
>>
>> This last approach can be taken quite far -- for example, yo= u could
>> enrich the type 'enc' so that the return type of = 9;get' varies
>> according to the encoding.
>>
>> Kind regards,
>>
>> Jeremy
>>
>>
>> --
>> -------------------------------------------------------= -----
>> Gerd Stolpmann, Darmstadt, Germany=C2=A0 =C2=A0 gerd@gerd-stolpmann.de<= br>
>> My OCaml site:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.camlcity.org
<= /div>
>> Contact details:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.camlcity.org/= contact.html
>> Company homepage:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.gerd-stolpmann.de=
>> -------------------------------------------------------= -----
>>
>


--001a11494168b80aba05482e14bd--