Accessors in Python (getters and setters)

[mystilleef]

Bruno Desthuilliers wrote:
> mystilleef wrote:
> > 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?
>
> *where* did I say *anything* that could *possibly* be taken as me not
> seeing the point of computed attributes ?
>
> What I'm saying here is that it's totally useless to duplicate default
> behaviour.
>

And who's doing that?

> >
> >>>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.
>
> Fine.
>
> Now : in a language with support for computed attributes, direct
> attribute access is the default r/w accessors.
>

Depends on your definition of accessors. Otherwise 97% of languages
provide direct access to an object's data attributes.

> >
> >>>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's the word you choose that I find really strange.
>

What's strange about it. If an object's data attribute is supposed to
state that it is false when there are no mark objects in the buffer,
and a third party accidently incorrectly changes the attribute to state
it is True for whatever reasons, you essentially corrupt the objects
state and render the whole system "unreliable," or "buggy". What again
is difficult to grasp?

> >
> >>>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,
>
> class Obj(object):
>   # ....
>   @apply
>   def is_active():
>     def fget(self):
>       return (self.something and self.computeThis()) \
>               or self.otherCondition()
>     def fset(self, val):
>       raise ReadOnlyError()
>     def fdel(self):
>       raise UndeletableError()
>     return **locals()
>
> According to *your* sayings, Obj.is_active is "behaviour"...
>

Not my saying.  OO says so.

> >>>And this is why many overzealous OO languages do "force" you to use
> >>>accessors.
>
> The only languages I know that "force" you to use accessors are
> Smalltalk and Ruby (and Ruby offers some syntactic sugar for 'default' -
> ie r/w - accessors).
>

Add Eiffel to the list. Java/C++/C#/Ada all recommend it by convention.


> > 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.
>
> I'm afraid it has very few to do with "robustness".
>

Your opinion.

> >>>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.
>
> Allo, Huston ?
>
> > The only
> > relevant model is my application's model, which should work regardless
> > of the language I use.
> 
> What to say...
> 
> 

...