On 20/03/2008, Yaron Minsky <yminsky@gmail.com> wrote:

> For what it's worth, not at Jane Street.  We've looked at using existential
> types once or twice, but have yet to find a really compelling application.
> We don't really use objects much either.
>
> I'm actually a bit puzzled by your original post, in that I don't have a
> clear sense of what kind of situations you've run up against where using
> poor-man's objects (e.g., collections of closures wrapped up in a bundle)
> doesn't do the job.  On the whole, I've found that collections of closures
> are easier to think about than objects precisely because you don't have to
> worry about subtyping.  I'd be quite curious to hear about concrete examples
> where that approach doesn't fit well.

Hi,

Apologies for chipping in so late.

I've used the "poor man's objects" approach quite often.  It's very
powerful and nicely modular - especially when creating frameworks
intended to be used by other programmers.  You can provide a module
which dictates an interface, while allowing clients of the module to
provide the precise implementation.

However, I always find it unravels quite quickly when a requirement is
added to store state on disk or send it over the network.  Records
containing closures aren't suitable for this.  I can use the O'Caml
marshalling system, but I don't really understand how this is useful
in practice, because data isn't portable between different
compilations of the program

To give a concrete, but slightly simple example (which I've hit in the
real world): you are writing a game writing framework.  You want to
allow client code to implement different kinds of Monster behaviour by
providing a function (game_state -> monster_state -> action).  The
complete game and monster state needs to be saved and reloaded,
possibly between different versions of the program.

Do any O'Caml design gurus have opinions on how best to do this?  I've
never been satisfied with any of the solutions I've come up with.

Regards,
Jim