Accessors in Python (getters and setters)

[mystilleef]

Steve Holden wrote:
> mystilleef wrote, making me somewhat tired of his/her repeated inability
> to get what's being said [sigh]:
> > Bruno Desthuilliers wrote:
> >>mystilleef wrote:
> >>>Bruno Desthuilliers wrote:
> >>>>mystilleef wrote:
> >>>>>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.
> >>>>
> This makes it somewhat obvious that you don't appear to fully understand
> the concept of coupling as applied to software systems.
>
> >>>>Time to burn your book and face reality. ObjA sends message Msg1 to
> >>>>ObjB. Part of the associated behaviour is that in responce to Msg1, objB
> >>>>changes it's own state. Practical result : ObjB's state has been changed
> >>>>by ObjA. Practical question : how do you hope to avoid this "hi
> >>>>coupling" (lol), apart from making all your objects totally autistic ?
> >>>>
> >>>Are you serious?
> >>
> >>Deadly serious. But I'm afraid you're still missing the point.
> >>
> >>>Well, you design an object that serves as a mediator.
> >>>All objects can then only interact with themselves and the mediator
> >>>only. Via signals, objects learn to automatically adjust their states
> >>>and respond to events.
> >>
> >>signal -> message -> method call -> change state.
> >>
> >>Spell it how you like, add as many indirection levels you want, it still
> >>boils down to the fact that *something* triggers the state change.
> >>
> > Riiiiight!
> >
> If you implement an accessor to change a class's instances' states,
> surely something has to call that accessor. You seem to be implying that
> such calls can only be made from within other methods of the same
> object, which (if true, which it isn't) would tend to leave each class
> in a vacuum where nothing else can affect its instances.
>
> Of *course* objects are subject to external influences: since you like
> the concept of coupling, how else could different components be coupled
> at all?

I gave the solution earlier. In well designed systems objects should be
responsible for updating their state themselves. In essence, objects
should learn to mind their own business. There will be some form of
coupling, but it should be minimal. Preferably the only coupling
permitted should be between an object and its mediator. Messages are
passed through the system via signals or events or established
protocols. What are the benefits? Well I can change the implementation
of any object at will without breaking the whole system. Or I can even
completely replace modules and objects with new ones without breaking
the whole system. If you are dealing with large source code, this is a
no brainer. And if you put a little effort into to it, you can create
objects that know when to initialize and destroy themselves as well as
update their states automatically. Welcome to event based programming.

(snip)

> >>>I'm sure glad I didn't burn my book.
> >>
> >>No comment.
> >>
> >>>>>>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.
> >>>>
> >>>>Does this imply a 'method call' *syntax* ?
> >>>
> >>>That's language dependent.
> >>>
> >>>>Given the existence of
> >>>>"computed attributes" (ie: support for 'attribute access' *syntax* with
> >>>>hidden accessors) and the possibility to redefine implementation (from
> >>>>default attribute r/w access to computed/controlled) without touching
> >>>>the interface, why advocate the *systematic* use of computed attributes
> >>>>when it's just duplicating the default behaviour ?
> >>>>
> >>>I'm not advocating anything.
> >>
> >>cf below on this.
> >>
> >>>I'm just stating the use case for
> >>>accessors and the wisdom behind them. My qualm with implicit accessors
> >>>remains the name issue.
> >>
> >>The "name issue" is *your* problem. And AFAICT, it's a "problem" because
> >>you refuse to free your mind from a "what's in the book" mindset.
> >>
> > What book are we talking about?
> >
> Well you should know, you're the one who wants to hang on to it. So
> please enlighten us, what is this source of knowledge that appears to
> contradict sound computer science?
>

High coupling is bad. Exposing critical states of an object is bad. Any
decent computer science book will tell you that.

> >>>>>>>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.
>
> Whereas you appear to feel that there can be no possibility if a crash
> because someone calls thing.is_active(True), and yet you repeatedly fail
> to demonstrate the difference. Which is why this thread has been so
> mind-numbingly long. As is pointed out AGAIN here:
> >>>>>>
> >>>>>>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.
> >>>>
> >>>>Indeed.
> >>>>
> >>>>>The reason to use them is if pre-conditions or post-conditions need to
> >>>>>be met. Or to control access to an objects states.
> >>>>
> >>>>Then why advocate *systematic* use of them ?
> >>>>
> >>>>(snip)
> >>>
> >>>I never advocated anything.
> >>
> >>You advocated
> >>"""
> >>1). Make all attributes of a class private/protected .
> >>2). If a "non-callable" attribute is going to be used outside a class,
> >>think about making it a property and name the property well, because
> >>you never know...
> >>"""
> >>
> > You use accessors when you need to control access to a data attribute.
> > That's not advocacy, that's common sense.
> >
> Perhaps so, but you still refuse to explain why it's better, when all
> you need to do is read or write the value of an instance's attribute, to
> define accessor methods to do it, introducing unnecessary (in Python)
> overhead in the process.

Obviously if I want to control access to an attribute, it means I don't
want it altered or I want to perform pre/post conditional computations
before/after the attribute is accessed. There's a reason it is called
access control.

> >
> >>>>>State - behavior is not something I made up, so it isn't subjective.
> >>>>
> >>>>The words (and the concept they describe) are not. Interpretation of
> >>>>what is state and what is behaviour is 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.
> >>>>
> >>>>It is.
> >>>>
> Am I the only one here who has lost track of this "'tis/'tisn't" stuff?
>
> >>>>>And behaviors are not
> >>>>>just necessarily getters/setters, they are methods of objects.
> >>>>
> >>>>Behaviour is how a given object reacts to a given message. *Nothing* in
> >>>>this implies the notions of attributes or methods. Attributes and
> >>>>methods are implementation details of the concepts of state and
> >>>>behaviour, and - while this is a common implementation of OO concepts -
> >>>> the choice to use non-callable attributes as representing the state
> >>>>and callable ones as representing behaviour is totally
> >>>>implementation-dependant.
> >>>>
> >>>I agree. And I already told you I think in terms of state and behavior
> >>>and not language dependent semantics.
> >>
> >>Then why do you advise "(making) all attributes of a class
> >>private/protected" and systematically using properties ?
> >>
> > Because you don't want third parties illegimately tampering with an
> > object's internal data and thus crashing your system?
> >
> In which case you write correct software and provide it with a thorough
> set of tests to allow you to modify it without worrying too much about
> breakage. Attribute access is part of an object's API just like method
> calls are.
>

Or I use accessors. Because I write tests doesn't mean third parties do
so, or even uphold the practice.

> You seem to think that every ill in software design can be legislated
> away by strangling design freedom with specific rules. I am afraid that
> experience will teach you this is far from the case: go look at the way
> that the "bondage" languages that use static typing (like Java and C++)
> still fail to impose the required typing discipline on a determinedly
> incompetent user.
>

Well I disagree. I used to share you mentality until I started managing
large source code. You need rules if you don't want your project to
collaspe under anarchy. And it is not until other people start using
your software in ways you never imagined that you realize the
importance of designing robust implementations upfront. When I wrote
less than a 1000 lines of Python code, I didn't care for
properties/accessors/public/private states or whatever. And I drank all
the Python philosophy cool aid I could get. But when you begin to get
emails about bugs in your software due to a third party inadvertently
changing states you never bothered to hide to begin with, then the
wisdom behind careful upfront planning begins to make sense.

> As has already been said, the Python philosophy is to provide the
> features that "consenting adults" (i.e. programmers who know what they
> are doing) can use most effectively to produce complex software systems
> to reasonable deadlines. Unfortunately not all the knowledge required to
> do this is readily available in books; the rest must come from experience.
>

That's all fine and dandy in the fantasy world. In the real world,
consenting adults do stupid things, and if I can prevent them from
doing it, especially when it affects me, I bloody well will.