2009/4/24 Mark Engelberg <mark.engelb...@gmail.com>:
>
> On Fri, Apr 24, 2009 at 2:21 AM, AndrewC. <mr.bl...@gmail.com> wrote:
>> If client code is using assoc and get then you haven't really started
>> thinking of your map as a new data type - you're still thinking of it
>> as a map.
>
> I disagree with this assertion, and the comparison to the SICP
> example. Unlike Scheme, Clojure is factored into a number of
> interfaces that are usable across a wide number of objects. assoc and
> get are part of the interface to set and get things in *any*
> associative structure. They are the logical choice to access fields
> of new "objects".
>From the client's point of view, is it necessary to know whether a
data is essential state or derived state ?
That is, is it really needed for the client to know whether the data
is a direct physical field of the "object" ?
I don't think so.
> It would feel rather un-Clojurian (to me) to have
> to invent new accessor functions for every single new datatype you
> create, rather than using the existing interface for associative
> access.
Again, it feels to me that it would be un-Clojurian if those accessor
functions where used in the lib itself.
But as an interface to be provided to clients of a lib, isn't it safer
to provide a level of indirection via accessor methods ?
And those accessor functions will have a lot of merits, and almost no
problem per see:
* you can generate them via macros, and then in the classical case,
there's almost nothing than to change a call to defstruct in a call to
your macro.
* by using functions, the client can benefit from compilation checks
(the compiler will not complain if the client types :nme instead of
:name, but will certainly if he types nme instead of name).
* Again, when defining a boundary for a library, I see this as an
advantage, while I would see this as a problem inside the library
itself
* and the client can leverage code completion in his favorite editor :-)
> The problem, of course, is that there is a language design principle
> that has evolved in the OO community that client code shouldn't need
> to know whether you are accessing a field or a method.
Yes, it's known as the "Principle of uniform access", as stated in
Bertrand Meyer's book.
Could you elaborate on why you see this as a problem ? Isn't that a
sound principle ?
Example: you have a first version of code where all fields are
accessed directly. And then a second version of code where you want to
enforce checks that were just informal with the clients (e.g. via
doc..).
With languages not having the possibility to easily do the principle
of uniform access (java does not have it, that's why so much of
redundant get/set lines of code are spread throughout our code bases,
obfuscating the real code :-( , blang, this simple new functionality
will break every client code.
> In Clojure,
> things kind of break down when you switch from using something in a
> "field-like" way to a "method-like" way.
Why do you say "things kind of break down" ?
(:key my-map) is a function call ? Everything is always (almost) a
function call in clojure ?
I think an idea could be to have (get) and (set) polymorphic via
multimethods (if they aren't already, maybe I don't know), but that
would certainly be a performance killer ?
Regards,
--
Laurent
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
