On Apr 23, 2010, at 11:48 PM, Mark Engelberg wrote:
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 can use functions if you don't like unencapsulated data.
Weren't you also advocating for serialization? Such things become much
simpler when one knows they are dealing with just data, and not the
results of some (possibly irreversible) function, of some other
possibly uninitialized dependents etc.
You need a level that is the data (even under some 'property' system).
The keyword-accessible, constructor-mapped fields are that layer. You
can always build functions on top of that.
Calculated getters/setters are one of those rich sources of incidental
complexity, with little real-world benefit IMO.
That said, defrecord is simply implemented in terms of deftype. People
can easily prototype alternatives for consideration.
Rich
--
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
