Tkinter callback arguments

[Alf P. Steinbach]

* 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