Thank you for your in-depth answer! My problem is that in this case, the sub-interfaces are actually very distinct from each other and it would make sense to have separate namespaces for them. So, SubElementA is really very different from SubElementB. Ironically the same API has another inheritance hierarchy where it indeed makes sense to do the opposite and only provide one namespace because those interfaces are thematically very similar to each other.
The main reason for re-exposing the base interface methods was that somebody who works with my wrapper wouldn't have to remember that SubElementA and SubElementB are extensions of a base Element interface. So in a sense there would be less of a 'cognitive overhead' for him or her, and one fewer namespace to import. On your suggestions about Clojure-ifying the wrapper: I'm actually working on another library that does this, and depends on the wrapper library in question. Again, thank you very much for taking the time to answer my question. On Tuesday, May 6, 2014 4:54:23 PM UTC+2, Alex Miller wrote: > > > On Tuesday, May 6, 2014 6:53:51 AM UTC-5, f...@kimchi.io wrote: >> >> Disclaimer: I'm new to Clojure programming. >> > > Welcome! > > >> I work on some Clojure wrapper functions for a Java API that mainly >> consists of interfaces. >> >> I wonder what the 'usual way of doing things' is regarding inheritance >> chains. >> >> Let's say there's an interface called *Element* that has a >> *getId()*function. A second interface, called >> *SubElement,* extends *Element*. I have two clojure namespaces for these >> two interfaces: *foo.element* and *foo.sub-element*. >> > > I suspect you probably don't actually need two namespaces for this, but it > depends on the api and your wrapping needs. > > In foo.element there is a wrapper for the getId() function: >> >> (defn get-id >> [^Element element] >> (.getId element)) >> > > ok > > >> >> Now my question is regarding foo.sub-element. Should I just redefine >> get-id in there? >> >> (defn get-id >> [^SubElement element] >> (.getId element)) >> > > There is no reason to do this - your prior get-id is fine. A SubElement is > an Element and Java turns these into the same virtual call either way. > > >> >> Or should I do: >> >> (defn get-id >> [^Element element] >> (element/get-id element)) >> > > There is no need to wrap a function like this. > > >> Or should I use potemkin in there? >> >> (potemkin/import-fn element/get-id) >> > > And I definitely wouldn't go to potemkin for this. > > >> Or should I not re-wrap this function call and work with both namespaces >> when dealing with SubElements? >> > > When you need to get the id, call the function in the element ns. If you > need something SubElement specific, call the functions in sub-element. You > may find that all of the functions in both ns'es could really go in Element. > > You may also consider not wrapping the api directly but instead > transforming your Java objects into Clojure data, working with it, then > transforming it back to Java if needed. There are obvious costs with > transformation and memory so this only sometimes makes sense, can't say > without knowing more about the API and the usage of it. One quick-and-dirty > tool for this is the "bean" function which takes a Java object and returns > a Clojure map based on it's "bean" properties (get*, is*). > > In general, rather than having explicit getter functions, Clojure > information entities (as maps or records) typically use keywords as keys > (the "fields" of the entity) and leverage the ability of keywords to invoke > themselves on a map as a getter function. I mention this because to take > advantage of this common pattern, you would need to do the transformation > from Java object to Clojure map/record. Again, hard to say whether that > makes sense for you. > > > >> >> What are the pros and cons to these different approaches? Thanks. >> >> >> -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
