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
