Hi David,
2009/4/20 David Nolen <dnolen.li...@gmail.com>:
> 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.
I'm not sure if I understand correctly what you're saying here. Are
you talking about this piece of code provided by Timo :
class Person2(object):
first_name = "first"
last_name = "last"
def get_name(self):
return self.first_name + " " + self.last_name
name = property(get_name)
, the get_name function ?
If so, then I think you may be wrong because get_name is not converted
somewhere into boiler plate code. I rather think this is one of the
dynamic strengthes of python being able to intercept calls on the fly.
Different langage, different way of handling problems (no macros
here).
Or is it really just syntactic sugar ?
Maybe I understand what you stated wrong, but I think here the
syntactic sugar not only has the value of saving some characters (not
having to type getName but just name), but also is an implementation
example of what Bertrand Meyer calls "the principle of uniform access"
in his "Object Oriented Software construction" book.
> 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.
"Property", in the OO world (at least java and C#), is often used to
mean access to a "property" via a function (or not, but the client
does not have to know about). "Attribute" or "Field", in the other
hand, are generally used to refer to implementation specific physical
storage.
As far as I know, Smalltalk does not *at all* provide access to
fields/attributes. So it is quite natural to then have to define
getters :-).
> 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
-~----------~----~----~----~------~----~------~--~---
