On Monday, June 18, 2012 8:01:47 AM UTC-6, tbc++ wrote: > > > Isnt that just creating an api? Everywhere the old model exists you need > to > > call a function to create the desired data structure and this adds > another > > layer of complexity that needs maintained. Not all conversions are > straight > > forward, may require additional context of whatever introducing the need > for > > deferred computation. > > Can you provide a concrete example (with code perhaps)? I guess I'm > not seeing where the problems arise. In this situation I normally > either, 1) create a new "fetch" function to create a new map of data > in the new format 2) provide duplicate data in the map that's computed > differently, 3) update the old code to the new map. > > Here at work we have a 20 year old application that is almost 100% > backwards compatible (the server can talk to much older clients). And > it does so by using pure data. The server has setup contracts saying > "this is what Project data looks like, this is what Company Data looks > like" and those contracts never change. The 3D Software Blender > (blender.org) operates on this same principle. After almost a decade, > their latest software can open 1.0 .blend files, and vice versa. All > these applications work off of unchanging data contracts. > > So I'm interested in seeing concrete examples of how your application > differs. >
Its not the external contracts that are changing but the internal contracts between namespaces... as I add features I add new requirements clarify my understanding and decide to replace them with new ones. I wish I could say just don't change them, but the internal contracts are "implementation details" no one uses them but me. If I decide to change them stuff breaks and that would be true in OO too, but in I know how to go about these refactorings incrementally in OO until the old abstractions fall away and become dead code, in clojure new abstractions mean lots of breaking changes and nothing works until everything works. I wouldn't mind sitting down with someone in the Denver area and getting some feedback on my code, eventually I would like to open source the code but I don't expect that to happen anytime in the near future. > > Timothy > -- 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
