* Steven D'Aprano:
On Wed, 04 Nov 2009 02:29:21 +0100, Alf P. Steinbach wrote:

For example, consider two rectangle classes R1 and R2, where R2 might
be a successor to R1, at some point in system evolution replacing R1.
R1 has logical data members left, top, width and height, and R2 has
logical data members left, top, right and bottom. With R1 direct
changes of left and top keeps the rectangle's size (since that size is
specified by width and height), while with R2 it changes the
rectangle's size. R1 is implemented with logical data members as
directly exposed data attributes. Some code in the system deals only
with R1 objects and for convenience or efficiency or whatever uses
direct modification instead of set_position method. Due to new
requirements it instead has to deal with R2 objects, with same
methods. But due to the direct modification of object state it now
changes the rectangle sizes, but at first it's not noticed since the
attempted rectangle position changes are very small. People get upset.
The bug is fixed. Time has been wasted.
If there is need for mutable rectangles, there is need for mutable
rectangles. Using properties instead of attributes doesn't help
In the example above using properties would have avoided the problem.

How would it have avoided the problem? Either of these would have the exact same semantics:

class R2(object):
    def __init__(self):
        self._secret = {'top': 0, 'bottom': 100}
    def _top_getter(self):
        return self._secret['top']
    def _top_setter(self, value):
        self._secret['top'] = value
    top = property(_top_getter, _top_setter)

vs

class R2(object):
    def __init__(self):
        self.top = 0
        self.bottom = 100

OK, I had a laugh. :-) You maintain that all doors are dark red, and show up a photo of two of your dark red doors as proof.

For R2, did you at *any* moment consider properties that emulated the internal representation of R1?

I'm putting it that way on the off-chance that you're not just pretending to not understand.


Given the semantics you specified

No semantics was specified in my example, quoted in full above.

However, the natural semantics is that various logical properties, such as left, top, right, bottom, width and height, can be varied independently.


it is strictly irrelevant whether R2.top is an attribute or a property. That's an implementation detail.

Happily that's incorrect. You might try to consider what properties are *for*, why the language supports them if they do nothing at all except adding overhead.


Cheers, & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to