Oh, I think I missed your suggestion of multimethods. They do in fact look pretty interesting, but I wasn't able to figure out how that would solve my problem - they look more like overloading than polymorphism to me. Would you mind posting a variant of my example that uses multimethods?
On 14/10/10 04:28, Armando Blancas wrote: > One thing that OOP and FP can have in common is the use of > polymorphism. With protocols and types you can implement your Java > design efficiently because you'll get basically the same interfaces > and classes. The thing about hiding the calls to instances of a data > type is only to make the client code not reply on the interop > notation, even if it is only to call a method on them, just like > Clojure core functions do. > > With multimethods you can have different versions of the same > function. You're right, you call it with the necessary data, one of > which will be the one that controls the dispatch. Both data types and > multimethods provide late-binding; the difference is that multi- > methods are objects turned inside-out, as if you keep a reference to > this (as a record with fields) and use in function calls. And each > method is a particular responsibility. That's how I think about it, > anyway. > > Either choice should be fine. I write Java interfaces for > implementations in Clojure when I want interop with Java, otherwise I > use multimethods and do it all in Clojure. > > On Oct 13, 1:37 pm, "Felix H. Dahlke" <[email protected]> wrote: >> I see. So instead of using interfaces and implementations of these, I >> would simply use closures, one for mock and one for production? That was >> actually my first attempt, but I didn't like it back then. >> >> Take this code for example - passing a function just to have it called >> feels weird: >> >> (defn load-page [provider name] >> (provider name)) >> >> (load-page (make-mock-provider) "home") >> >> In Java, this would probably look like this: >> >> class PageLoader { >> Provider provider; >> >> PageLoader(Provider p) { >> provider = p; >> } >> >> Page loadPage(String name) { >> provider.loadPage(name); >> } >> >> } >> >> PageLoader l = new PageLoader(new MockProvider()); >> l.loadPage("home"); >> >> Then again, it might just feel weird because I've gotten very used to >> OOP. In my Java code, loading pages is a responsibility of the >> PageLoader and it delegates it to the Provider. Objects have >> responsibilities and send messages to each other to fulfill these, >> that's OOP. >> >> In functional programming, there's simply a function that has a certain >> functionality, and everything it needs to fulfill it has to be provided >> by the caller. That's at least how I understand it by now. >> >> Maybe I should just call the function returned by (make-mock-provider) >> directly? The interface in Java has the great benefit of ensuring type >> safety (plus there's no closures yet, so it's the only way), but does >> this make sense in a dynamic language? I mean, if I passed an >> implementation of the wrong interface or a closure with the wrong number >> of arguments, wouldn't both situations result in weird runtime errors? >> >> On 12/10/10 22:34, Armando Blancas wrote: >> >>>> Back to my question: Am I trying to do Java in Clojure? Is there a more >>>> Lisp-y way to do this? >> >>> You can hide the types so your client code is more lispy: >>> (defn load-page [prov] (.loadPage prov)) >>> ;;test >>> (def mp (make-mock-provider)) ... (load-page mp) >>> ;;production >>> (def prov (make-provider)) ... (load-page prov) >> >>> Depending on your app the provider could be a singleton and need not >>> be passed to each function. Another option is multimethods, in which >>> case you'd be using mock functions with an argument that would >>> indicate which version to dispatch to. >> >>> As for the repl, I think it works just as well for bottom-up and top- >>> down development. I use it for both all the time and to avoid throw- >>> away tests I write them top-down, black-box for only what's visible to >>> client/interop code first, then move down the layers as the code is >>> more mature and stable. I'm not really into TDD but I depend on a test >>> suite as complete as I can get it. >> >> >> >> signature.asc >> < 1KViewDownload >
signature.asc
Description: OpenPGP digital signature
