A few meandering observations: I like the latest change to include a this argument. It makes the number of arguments line up which is a good thing.
I like the idea of defrecord for the common case, rather than having to request default implementations of various interfaces within deftype. Still, I think the splitting of deftype and defrecord has merely delayed, not eliminated, the need to eventually find a convenient, general scheme for layering in default implementations of interfaces. I look forward to seeing how this evolves. I like Rich's description of Clojure's datatypes/protocols as "opinionated, and mostly agree with his manifesto. The one opinion I have the most difficulty with is: "It has always been an unfortunate characteristic of using classes for application domain information that it resulted in information being hidden behind class-specific micro-languages, e.g. even the seemingly harmless employee.getName() is a custom interface to data. Putting information in such classes is a problem, much like having every book being written in a different language would be a problem. You can no longer take a generic approach to information processing. This results in an explosion of needless specificity, and a dearth of reuse." OO programmers write employee.getName() methods to preserve the option of doing something more sophisticated later, which isn't readily possible once all your clients start using employee.name everywhere. So if you really want to create a generic approach to information processing, it seems like the best approach is to address the underlying reason that these custom interfaces are needed. For this reason, I've always found appealing languages which let you optionally write getter/setter methods that "hook into" the standard field access syntax. This lets you start out with your fields public, and let your clients use the standard field access "interface". Later, if you realize you need to do something special, you can easily add a custom getter without breaking your clients. As far as I know, Clojure doesn't currently make any attempt to address this problem of allowing a standard way to access public data from an object, while preserving the option of doing something more sophisticated later. So a programmer is still forced to choose between the convenience of keyword lookup of data, versus a protocol filled with "get-name" functions to preserve future flexibility. Ideally, I'd like to see a way to allow me to write a program using (:name employee), and later, if I need to, customize the employee datatype so that (:name employee) actually dispatches to some other function. Ditto with (assoc employee :name "Mark") (for example, to validate the data in some way?). If I'm off-base, and these issues are easy to currently workaround in Clojure, I'd love to hear more about how others are handling this in their own programs. -- 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
