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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 36CB9BBC1 for ; Fri, 28 Mar 2008 11:44:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhICANBo7EdC+VLvc2dsb2JhbACRMwEMAwQFCRSTcYVO X-IronPort-AV: E=Sophos;i="4.25,569,1199660400"; d="scan'208";a="24295172" Received: from wx-out-0506.google.com ([66.249.82.239]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Mar 2008 11:44:43 +0100 Received: by wx-out-0506.google.com with SMTP id h27so195049wxd.15 for ; Fri, 28 Mar 2008 03:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ccZNToYlbM3u4Df6Q1nEb0SjUHtSAb0M/eYhlfYJ8L4=; b=Xq7WwWPppUICrspcIyGvTKWMtDwhaouQN0IEP4oEJy3qIMbDwCuQykyTQUarWhamb4k43g1xGz4K8lZS4rAutpsa0Cb+EmHwESW9vigJddv7Hzp0OM84rloGfQ/3MLLTxql1qZ9CiNjYrUkU3OkEpOHHKTmaIL4jbPcRchHis2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cibJyHFdSqRbM/RJ28obtzpx5ZgNEkACjh0ZTq1qxhYaF1ILPtAT7RshP3VOL6AjJmNyQsbiqsCrZcldMLLsTevo3w6FpdmLOaAdpJZrL+4gKVhBJmBXQ75tBh/ja+XJQPlgRb8t+HysL+/qZOS0MwlUHZ/MZ3krvi6rUQPbjJc= Received: by 10.114.153.18 with SMTP id a18mr3315265wae.127.1206701081650; Fri, 28 Mar 2008 03:44:41 -0700 (PDT) Received: by 10.115.111.17 with HTTP; Fri, 28 Mar 2008 03:44:41 -0700 (PDT) Message-ID: Date: Fri, 28 Mar 2008 10:44:41 +0000 From: "Jim Farrand" To: "Caml Mailing List" Subject: Re: [Caml-list] The Bridge Pattern in OCaml In-Reply-To: <891bd3390803191907q5838ee66u83cb35e549805af0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4a051d930803190929q60d31012kb6c9d2b03a2d2ca6@mail.gmail.com> <0A1AD394-2F3B-488E-926B-1839C7C321E6@erratique.ch> <4a051d930803191044t1a1e9cb6h65ddbbda24cd7e1d@mail.gmail.com> <4a051d930803191106v74fa5de3j92530c3bf15ea9d5@mail.gmail.com> <891bd3390803191907q5838ee66u83cb35e549805af0@mail.gmail.com> X-Spam: no; 0.00; ocaml:01 yaron:01 minsky:01 yminsky:01 existential:01 subtyping:01 modular:01 o'caml:01 marshalling:01 compilations:01 o'caml:01 monster:98 monster:98 closures:01 closures:01 On 20/03/2008, Yaron Minsky 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