<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 13 Jan 2012, at 13:57, Richard Carlsson wrote:</div><blockquote type="cite"><div>There seems to be a lot of confusion going on here between *interface* (API) and *dispatch* (redirecting the API calls to the actual implementation depending on the data structure). I have only suggested a unified API; not a generic dispatch mechanism.<br><br>"Tuple modules" (please call them Parameterized modules or Abstract modules - the implementation-as-tuples is a temporary hack, and you should treat them as opaque objects just like funs) are not needed, because there is nothing here to parameterize. If all dict-like modules implement the same API, it's enough to use the module's name. For example:<br><br> MyDict = orddict,<br> ...<br> D = MyDict:new(),<br> ...<br><br>What you *could* do is to parameterize the module that uses the dictionary:<br><br> -module(my_module, [SomeDict]).<br> ...<br> foo() -><br> D = SomeDict:new(),<br> ...<br><br>and then you could easily change implementation as you like:<br><br> M1 = my_module:new(orddict),<br> M1:foo(),<br> M2 = my_module:new(ets),<br> M2:foo(),<br> ...<br><br>That said, I think Clojure's protocols (which are a way of dynamically getting the same effect that you get with Haskell's type classes) are a neat idea that would probably work well with Erlang. But that's a different story.<br></div></blockquote></div><br><div>A quick question Richard, if I may. How do you see this looking in the consumer's (Erlang) code? I can see a bunch of ways to make the definition available and do codegen from it etc, but it's the consumer who's suffering at the moment for lack of a decent abstraction. So far I've thought about having the 'protocol' declaration whilst I'm build and in a parse transform (or post build code instrumentation step, even at runtime I suppose) looking for an implementation that matches the call site. Rewriting the call to the 'appropriate' handler isn't hard, but the problem I'm having is understanding what is 'the right way' to resolve the implementation that should be used.<span class="Apple-style-span" style="font-size: 13px; "> </span></div><div><span class="Apple-style-span" style="font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 13px; ">I do also worry that without some kind of 'namespaces' concept, this could get messy in a hurry. Perhaps the solution to that is to allow the consumer to control the implementations which are in scope, but again, I'm not sure whether that's even sensible let alone usable.</span></div><div><span class="Apple-style-span" style="font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 13px; ">I'd love to know your thoughts about this, as I'm on a mission to rid my Erlang code of voluminous boilerplate and this issue of dynamically binding an API call to an implementation is very high on my hit list.</span></div><div><span class="Apple-style-span" style="font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 13px; ">Cheers,</span></div><div><span class="Apple-style-span" style="font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="font-size: 13px; ">Tim </span></div></body></html>