A couple of things. In your initial example, you conflated some things. One
issue is simply a matter of convenience- defining a getter so that you can
use Python object property access (via the dot operator). Personally I don't
like this idiom at all (you find it in Objective-C 2.0 and Javascript).
It's simply syntactic sugar that gets converted into another (hidden) form.
Then support for getters/setters is very much a "macro"-like trick, they
will get converted into the standard form somewhere. So all that's
happening here is that you are saving on typing. The correct answer for this
is write the syntactic sugar yourself with some macros.
Data encapsulation is another issue. Functions provide a well-defined
interface. If the underlying representation is going to change provide a
function. I would like to point out that in Smalltalk (the OO grandaddy) I
am pretty sure there is no such thing as property access, you must provide a
method.
Data encapsulation in Clojure is far less of an issue than it is with most
OO languages, as data is immutable anyway. Encapsulation support in a
language that that don't truly protect instance variables is pretty
pointless anyway as well as being overrated IMO. For example, JavaScript has
no such encapsulation, yet large programs can be written/scripted with it
(FireFox).
Again if you want the convenience of setters/getters write a macro to save
you some typing.
On Mon, Apr 20, 2009 at 12:13 PM, Timo Mihaljov <noid....@gmail.com> wrote:
>
> Matt Clark wrote:
> > Maybe I'm missing something, but what is wrong with Stuart Sierra's
> > solution? I quite like it, and it would probably be more appealing if
> > it were encapsulated into a macro.
>
> Frankly, it seemed like a good answer to the wrong question [1] instead
> of being a recurring and widely known idiom in the Clojure community.
> Stuart's disclaimer ("I won't claim this is an elegant solution, but
> it's similar in spirit to your Python example") left me feeling that his
> answer was what I asked for, not what I need, if that makes any sense.
>
> To put it another way, any answer involving custom support code (new
> macros or the like) is not the one I'm looking for. Being able to modify
> the language is very cool, but not being able to solve a simple problem
> with a language that thousands of people use all the time suggests to me
> that I'm trying to solve a problem that everyone else sidesteps
> altogether.
>
> Thanks to everyone for your replies. An don't worry, I'll stop with the
> newbie questions someday :)
>
> [1]
>
> http://blogs.msdn.com/ericlippert/archive/2009/04/13/restating-the-problem.aspx
>
> --
> Timo
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
