mystilleef wrote: > Bruno Desthuilliers wrote: > >>mystilleef wrote: >><ot>Please don't top-post</ot> >> >>>On State and Behavior: >>> >>>To understand objects in terms of state and behavior you need to >>>absolve yourself from implementation details of languages >>>and think at an abstract level. >> >> >> >>>Take a button object, for example. It has state and behavior. Possible >>>states may include, is_active, is_focused, is_mapped, etc. Behavior is >>>what the button does when it responds to events, (e.g when you click on >>>it, or drag it, or position a pointer over it.) If you've done any form >>>of event based programming (GUI/Games/Simulation), this method of >>>thinking becomes natural. >>> >>>As you can see, when I'm designing a button object, I don't care what >>>Python does with is_active. I don't care how it accesses. I don't care >>>what is_active means to Python. I don't care about Python's __get__ >>>/__set__ special/latent functions or implementation details. is_active >>>to me and every other developer is a state of the button object. And at >>>that level that's all that matters. Python can tell me it's just ones >>>and zeros for all I care. >>> >>>In very well designed systems, the state of an object should only be >>>changed by the object. >> >>... as a response to a message. >> >> >>>For example, a third party randomly changing >>>is_active, (which Python lets you do freely and easily) >> >>Unless you make it a read-only property. >> > > So you see the purpose of accessors then?
*where* did I say *anything* that could *possibly* be taken as me not seeing the point of computed attributes ? What I'm saying here is that it's totally useless to duplicate default behaviour. > >>>from False to >>>True may crash your GUI. >> >>>And I'm not making this up. Things like this >>>do really happen depending on the whackyness of your toolkit. So >>>sometimes, it is my duty to protect the state of an object. Especially >>>if its state cannot afford to be corrupted rendering the system >>>unstable. And situations like this are found a plenty in event based >>>programming. Which is programming objects based almost entirely on >>>state and behavior. As you can see this has nothing to do with Python >>>vs Java's vs X's implementation of accessors and how using them sucks, >>>or how they aren't Pythonic. Some domains just require this stuff. >> >>Properties *are* 'accessors'. >> > > I never said they weren't. Fine. Now : in a language with support for computed attributes, direct attribute access is the default r/w accessors. > >>>One of the requirements for designing robust object systems is ensuring >>>the state of objects aren't easily contaminated. >> >>"contaminated" ??? >> > Make an object's state unreliable. See above example. That's the word you choose that I find really strange. > >>>That "state" is the >>>objects data (read: stuff the object needs to do something "reliably"). >> >>Makes no sens to me. >> > > is_active is an object's data, class Obj(object): # .... @apply def is_active(): def fget(self): return (self.something and self.computeThis()) \ or self.otherCondition() def fset(self, val): raise ReadOnlyError() def fdel(self): raise UndeletableError() return **locals() According to *your* sayings, Obj.is_active is "behaviour"... >>>And this is why many overzealous OO languages do "force" you to use >>>accessors. The only languages I know that "force" you to use accessors are Smalltalk and Ruby (and Ruby offers some syntactic sugar for 'default' - ie r/w - accessors). > It's not because they hate you or aren't aware of the >>>convenience of having direct access to an object's attributes. It's >>>just because these languages convenience/robustness ratios are >>>different. I'm afraid it has very few to do with "robustness". >>>Thinking in terms of callable vs non-callable is not helpful for me, >>>because it isn't high level enough. >> >>Allo, Huston ? >> >> >>>Thinking in terms of state and >>>behavior is, because it works regardless of programming language or >>>implementations. This is the reason I like working with Python. I >>>wanted a language that didn't bore me with it semantics and allowed me >>>to focus on design. Let me reiterate, I'm not obsessing over language >>>semantics, I just need practical, not religious, solutions for my >>>problem domain. >> >>Using properties instead of explicit getters/setters is pragmatism, not >>religion. Using the default get/set mechanism when there's no specific >>reason to do otherwise is pragmatism too. And understanding the object >>model and idioms of the language you're using is IMHO the very pragmatic >>thing to do... >> > > Again, the object model of the language is irrelevant. Allo, Huston ? > The only > relevant model is my application's model, which should work regardless > of the language I use. What to say... -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list