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? > > 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. > > 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 "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, with regards to our example. > > And this is why many overzealous OO languages do "force" you to use > > 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. > > > > 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. The only relevant model is my application's model, which should work regardless of the language I use. -- http://mail.python.org/mailman/listinfo/python-list
