Accessors in Python (getters and setters)

[Bruno Desthuilliers]

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.

> 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'.

> One of the requirements for designing robust object systems is ensuring
> the state of objects aren't easily contaminated. 

"contaminated" ???

> That "state" is the
> objects data (read: stuff the object needs to do something "reliably").

Makes no sens to me.

> 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...

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"