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 '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list