Accessors in Python (getters and setters)

[mystilleef]

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.