Accessors in Python (getters and setters)

[mystilleef]

Gerhard Fiedler wrote:
> On 2006-07-15 06:55:14, mystilleef wrote:
>
> > In very well designed systems, the state of an object should only be
> > changed by the object.
>
> IMO that's not quite true. Ultimately, the state always gets changed by
> something else (user interaction, physical events); very few objects are
> completely self-contained in their behavior.
>

Then in those cases the system becomes a victim of high coupling.

> In most systems (and you possibly have written some of them) are objects
> whose state gets changed by other objects -- possibly through the
> intermediation of setter methods that do nothing else but set the state.
> There's no conceptual difference between directly setting the state or
> calling a setter function that does nothing else but directly setting the
> state -- except for one unnecessary level of indirection in the latter.
>

It depends. If certain conditions need to be met before changing the
state of an object, then arbitrarily changing it can be dangerous. I
gave an example earlier.

> > For example, a third party randomly changing is_active, (which Python
> > lets you do freely and easily) 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.
>
> That's quite true, but a setter that does nothing but change is_active
> doesn't prevent this. If there is logic necessary to prevent state changes
> in certain situations, this should be implemented. But whether you then
> call this a part of the "behavior" (looking at the implementation as being
> a setter method) or a part of the "state" (looking at the implementation as
> being an added feature of the attribute) doesn't really make an objective
> difference.
>

Of course using setters for the sake of just using them is pointless.
The reason to use them is if pre-conditions or post-conditions need to
be met. Or to control access to an objects states.

> > So sometimes, it is my duty to protect the state of an object.
>
> Of course.
>
> > 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.
>
> Yes, but you seem to still be stuck in the paradigm that setting the state
> is behavior if it comes from the outside -- probably because some languages
> implement that way.
>

Not at all. Behaviors are just methods of an object. They are behaviors
whether they are called internally or externally.

> I'm not (yet) a Python programmer. To be honest, the one single feature
> that attracted me to Python is the structuring by indenting... I never
> understood why we have to indent (to be able to read) /and/ brace (to make
> the compiler happy) in other languages -- I always thought that if
> indenting helps me to understand the structure, the compiler should be able
> to read exactly that :)
>
> I come from a mostly C/C++/Java/PHP background, apparently similar to
> yours. GUI, embedded, whatever. But I can understand that the difference
> you are making is not based in a concept, it is based in an implementation.
>
> It is an artificial difference to say that
>
>   o.is_active = true
>
> is modifying state, whereas
>
>   o.set_active( true )
>
> is dealing with behavior. Either way you are changing the state. Behavior,
> that is, doing something, implies state change, one way or another,
> sometimes relevant, sometimes not. There are (often embedded) systems, and
> well-designed ones, that basically don't deal with what you call behavior
> at all and handle everything through state change (of signals). Such
> systems can be rock-solid and quite complex, and have a lot of "behavior".
> And there are systems that do everything through what you call behavior
> (e.g. getter/setter type implementations). Both types can work, both can
> achieve the exactly same; this is just an implementation detail.
>

If all set_active does is change is_active's state, then set_active is
pointless. See above for my point on the issue.

> > And this is why many overzealous OO languages do "force" you to use
> > accessors.
>
> I'm not sure why you keep on harping on this. It seems to have been clearly
> stated that in Python, every attribute /is/ an implied getter/setter pair
> -- it's up to you to just let the language use the default (simple)
> implementation, or override it with your own logic. It is also up to you to
> call this added logic then a feature of "behavior" or of "state".
>
> > Thinking in terms of state and behavior is, because it works regardless
> > of programming language or implementations.
>
> Agreed. But the distinction is not universal, objective, it is subjective.
> Where you make it is your choice. As the examples above show, there are
> well-working solid systems out there that work on both ends of your
> spectrum: only behavior is exposed, or only state is exposed. Both can
> achieve the same. It is a subjective choice to call this
>
>   o.is_active = true
>
> state or behavior... the underlying setter implementation for is_active can
> do everything you want your behavior to be -- or it can be the simple
> straightforward default setter. It's just a subjective thing to say that
> this is in the realm of behavior or of state. Didn't you say that state
> changes can crash a system? That's behavior, as far as I am concerned :)
> And there is little if any behavior that doesn't change the state --
> especially setters are known to do that :)
>
> Gerhard

State - behavior is not something I made up, so it isn't subjective. It
is a common term used in OO literature. In fact, the only reason I used
it is because I thought is was common knowledge. And behaviors are not
just necessarily getters/setters, they are methods of objects.