On Mon, 20 Apr 2009 21:53:41 +0200
Laurent PETIT <laurent.pe...@gmail.com> wrote:
>
> 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.
>
I think this last point is the most important aspect of Python's
property/descriptor feature.
What may not be obvious about his example is that after creating this
getter and it's associated property, you don't have to change the
consumers of Person instances. This is because a property translates
assignments and references into calls to the getter and setter
respectively; one can continue to write
print "Hello, " + some_person.name
and the getter is transparently called when the attribute reference is
evaluated. This means that you can create interfaces that start out
using direct attribute accesses, eliminating all trivial
getters/setters, without worrying that it will break your API if you
later change your mind.
> > 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.
This is starting to stray a bit from the original topic of the post, but
I did want to point out that because Javascript provides closures, one
can implement enforced data hiding using an idiom that I picked up from
Douglas Crockford's "Javascript: The Good Parts". This thread has gotten
me thinking about whether this idiom could be adapted to (or inspire a
new idiom for) use in Clojure...
function make_person(first_name, last_name) {
var private_member = something();
function private_function(x) {
// do stuff
}
return {
name: function () {
return first_name + ' ' + last_name;
},
public_function: function (a, b) {
// do stuff
return private_function(a + b);
}
};
}
The return statement returns an object literal that contains the public
interface of a person, and any members inside it have access to private
data members and functions defined in the constructor's scope, by virtue
of closure. I had a new appreciation for Javascript after seeing it.
Of course, this doesn't really suggest a good way to solve the OP's
problem, but I thought it interesting in regards to the data hiding
aspects of this thread.
On the other hand, Javascript's unification of objects and maps (while
occasionally quirky) might point to a useful technique in Clojure, where
maps are promoted as perhaps *the* data structure of choice, in most
cases preferred to (for utter lack of a better term) "real" objects.
-Kyle
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
