Sounds like a good candidate for the Clojure documentation project. On Mon, Dec 10, 2012 at 5:33 PM, Mikera <mike.r.anderson...@gmail.com>wrote:
> Some thoughts from various Java libraries I have wrapped: > > - Normal functions are generally best for wrapping > - It can often make sense to have a protocol that dispatched on the type > of the Java object and/or clojure params for polymorphism and extension. > Your public functions should often call the protocol functions (after > applying any defaults / validation / argument re-ordering etc.) > - It can make sense to turn mutable Java APIs into immutable Clojure ones > in some cases. Depends on whether the Java API allows this and how much you > care about performance. > - Try to type hint with interfaces or abstract base classes only. It gets > messy if you start making special cases for specific concrete types, and is > probably a sign of incoherent design if you feel you need to do this. Best > to figure out the small set of Java abstractions that you want your API to > work with / expose and stick to functions that maipulate these. > - Ensure you have zero reflection warnings. Apart from the performance > cost, they are usually a sign of a logic error. > - I usually find the need for a few constructor functions to handle > different use cases. Not sure that having a 1-arg constructor from a map is > the best low level option - this will depend on the Java API. Often a 0-3 > arg constructor, a clone constructor or one that takes a List<Object> seem > to be the most common. If there are a lot of options, I'd tend to make > these keyword params. > - Keyword args are your friend - they often translate to setXXX or addXXX > calls in a Java API and enable you to wrap quite a lot of complexity as > extra parameters to one function. I think these are better than map > parameters on average, YMMV. > > > On Monday, 10 December 2012 13:21:09 UTC+8, Michael Grubb wrote: >> >> I've been searching for some best practices when it comes to wrapping >> existing Java libraries to make them more "clojurized." >> Unfortunately I've not found much. >> While I know enough to make something that works for me, I'd like to >> write it in such a manner that it can be used (and read) by others >> and not make them cringe in doing so. >> >> My first attempt was to simply write function wrappers around the java >> interop calls. >> This worked fine and was maintainable. Then I discovered 'lein check' >> and saw a whole lot of warnings about reflection. >> >> This led me to my second attempts. This time I wrote multimethods to >> dispatch on type of arguments and in each defmethod argument list >> I gave type hints for each argument. This indeed resolved the reflection >> warnings, but I fear that the resulting code is rather messy and not >> too pleasant to read either. This made me wonder if all the type >> checking I'm doing in the multimethod dispatch function isn't just as bad as >> the reflection that would take place. >> >> For my purposes and this particular library I'm not really concerned with >> performance, yet someone else may be. Can anyone offer me some >> advice on how best to approach a project like this? >> >> Kind regards, >> Michael >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- Grant Rettke | ACM, AMA, COG, IEEE gret...@acm.org | http://www.wisdomandwonder.com/ Wisdom begins in wonder. ((λ (x) (x x)) (λ (x) (x x))) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
