Accessors in Python (getters and setters)

[Bruno Desthuilliers]

mystilleef wrote:
> Bruno Desthuilliers wrote:
> 
>>mystilleef wrote:
>>
(snip)

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

That's exactly what you recommended: "make all attributes
private/protected (...) If a data attribute might likely be an API,
think about controlling access to via "properties""


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

something that let me access an attribute.

> Otherwise 97% of languages
> provide direct access to an object's data attributes.

But not 97% of languages provide support for computed 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?

The choice of the word "contaminated".

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

Chapter and verse, please ?

now :
class Obj(object):
  def __init__(self):
    self.is_active = False

Now, 'is_active' is state again ?

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

Java/C++/C#/Ada all recommend it because they have no support for
computed attributes, which means that you cannot change implementation
without breaking the interface.


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

what's the exact difference in "robustness" between:

class DreamItisRobust(object):
   def __init__(self):
     self._attr = 42
   def get_attr(self):
     return self._attr
   def set_attr(self, attr):
     self._attr = attr

and

class DontCare(object):
  def __init__(self):
    self.attr = 42


???

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