From: Steffen Smolka <smolka@cs.cornell.edu>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: Jeremy Yallop <yallop@gmail.com>, Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] namespace inside object?
Date: Thu, 9 Feb 2017 18:54:20 -0500 [thread overview]
Message-ID: <CAGh2ivCGkH8adD-Bw5FD4bEJWC23iW6srFJA9GSzbuUo-hUn-A@mail.gmail.com> (raw)
In-Reply-To: <1486683451.12698.83.camel@gerd-stolpmann.de>
[-- Attachment #1: Type: text/plain, Size: 5826 bytes --]
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>
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 <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? 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
> ------------------------------------------------------------
>
>
>
[-- Attachment #2: Type: text/html, Size: 8374 bytes --]
next prev parent reply other threads:[~2017-02-09 23:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 20:36 Steffen Smolka
2017-02-09 22:55 ` Jeremy Yallop
2017-02-09 23:19 ` Steffen Smolka
2017-02-09 23:37 ` Gerd Stolpmann
2017-02-09 23:54 ` Steffen Smolka [this message]
2017-02-10 2:01 ` Yaron Minsky
2017-02-10 3:16 ` Steffen Smolka
2017-02-10 3:32 ` Yaron Minsky
2017-02-10 9:38 ` Leo White
2017-02-10 14:40 ` Evgeny Roubinchtein
2017-02-10 15:16 ` Markus Mottl
2017-02-10 15:49 ` Leo White
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGh2ivCGkH8adD-Bw5FD4bEJWC23iW6srFJA9GSzbuUo-hUn-A@mail.gmail.com \
--to=smolka@cs.cornell.edu \
--cc=caml-list@inria.fr \
--cc=info@gerd-stolpmann.de \
--cc=yallop@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox