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.
