I've maintained 5+ year-old Clojure applications and the Uniform Access Principle was not a concern for me.
Bigger concerns for me were the Single-Responsibility Principle, and conversely, the Big Ball of Mud Anti-pattern. But I think these are both concerns on any large, old program in any language. On Sat, Oct 18, 2014 at 10:35 PM, Brandon Bloom <brandon.d.bl...@gmail.com> wrote: > I don't know who is the outlier. The point is that Scala, for instance, >> has explicit support to hide the distinction between accessing a value >> and computing a value. The point is to support the uniform access >> principle. >> >> http://en.wikipedia.org/wiki/Uniform_access_principle >> > > In one sense, accessing data and calling functions uniform: keyword > lookups are just function calls themselves. In another sense, lookup by > keyword requires implementing ILookup etc rather than changing a simple > function. > > If you take the stance that the data is your API (and you should), then it > makes sense that switching from a keyword lookup to a function call is a > breaking change! It shouldn't be easy to rip the data-rug out from under > your callers. At least it *is* possible, depending on how far you're > willing to go down the Clojure interfaces rabbit hole. Of course, this > equation changes even more in favor of Clojure's keywords approach if your > client lives across the network. > > That said, if you're not sure if you want to make the data your API, you > can reserve the right to change your mind later quite easily. Let's say you > have (ns user) and want to create a username function: > > (def username :username) ; tada! > > Yes, this requires some foresight. Back in my C# days, the guidance was > "always make everything a property". That was especially important if you > cared about binary compatibility, since changing from a readonly field to > a getter was a breaking ABI change. But you know what, over quite a few > major and minor releases of our widely used APIs, I don't recall ever once > changing from a trivial `return foo` getter to more complex getter logic. > The expectation that a getter is a simple data read was always a core part > of the public interface. > > -- > 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. > -- 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.
