Accessors in Python (getters and setters)

[Bruno Desthuilliers]

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.

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

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

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

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

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

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



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