On Sun, Jun 17, 2012 at 8:06 PM, Kurt Harriger <kurtharri...@gmail.com> wrote: > One of the sayings I hear reiterated is "it is better to have 100 methods > that operate on one data structure than 10 methods that operate on 10 data > structures." Yet how is this different from one large interface with a > hundred methods?
You've misunderstood the intent behind the quote. By using a generic data structure, you have more functions available to you - and you don't have to duplicate each function for each different data type (10 methods that operate on 10 data structures is 100 methods but really only 10 different ones). By using a generic map, all functions that work on maps are available to you. By choosing a specific data structure for your "object", you are forced to write a new version of every function you might need. Your one line getters might be trivial enough (one for every property) but now you can't use your object with any function that takes an associative data structure and you have to write adapter functions for each of those functions too. > Now if you want to change a map so that :area which was > previously an precomputed value to a deferred computation you now need to > override ILookup, ISeq IMapEntry, perhaps others to ensure keyword lookups.. This is an API change, just like changing a Java interface. In OO-land folks get very blasé about changing data structures because they obsessively wrap everything up and they seem to ignore all the extra code they have to write to do anything with these objects. By designing an API based on a data structure, there's a lot less code needed to interact with it. If you change the API, yes, client code needs to change, just like in Java. If your object's API changes so that area is not precomputed and becomes a deferred computation, that is still a change to the contract (because the performance of accessing area changes - and calling getArea() repeatedly now becomes expensive rather than a trivial operation). If you're designing a data-based API, you need to consider what to provide and what the characteristics of each part of the data structure are, just as you need to with a Java interface. What's missing in Java interfaces are any consideration about performance and what the abstraction really means. > Its possible something just hasn't quite clicked yet Quite possible. If you have a long history of OO thinking, FP can be really hard to get into. I find it much easier to teach FP to folks who've had little or no OO experience. Getting OO folks away from thinking about state as something inside an object that they can just poke at can take a while :) > Many libraries have been deprecated, replaced and rewritten due to > breaking changes to clojure core or other libraries and that worries me a To be fair, the shift in contrib from 1.2 to 1.3 was more about getting rid of unmaintained code and ad hoc experiments and focusing instead on well-maintained libraries that are useful to real world developers. Several of the authors of the abandoned parts of monolithic contrib will be very quick to tell you not to use their old code because it was half-baked or otherwise flawed... > I can't sit on the side lines entirely cause I just wrote a reasonably > complex clojure program that I need to maintain still :) And I have thousands of lines of Clojure in production too, and a database with millions of users - and thousands more signing up every day. We started on Clojure 1.2 but switched to 1.3 early on and went to production with Alpha 7 (or 8) and now we're on Clojure 1.4 (and testing on nightly builds of 1.5, just to be sure we're future proof). Where we needed libraries from 1.2 that were not 1.3 compatible, we made them compatible and worked with the library maintainers as much as we could. clojure.contrib.sql moved to clojure.java.jdbc and is actively maintained because of that. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
