Tkinter callback arguments

[Alf P. Steinbach]

* Diez B. Roggisch:
> Alf P. Steinbach schrieb:
>> * Diez B. Roggisch:
>>>> Your comment about "computed" makes it more clear what that's all 
>>>> about.
>>>> Also Bertrand Meyer (Eiffel language creator) had idea like that, he
>>>> called it "referential transparency". But I think when Python has this
>>>> nice property mechanism, why do people change direct data attributes 
>>>> into
>>>> properties and not the other way around or not at all, I mean using 
>>>> only
>>>> properties for logical
>>>> data attributes  --  e.g. assuring correctness first via read-only
>>>> property?
>>>
>>> I fail to see where read-only-ness of an attribute is a priori more 
>>> correct
>>> than having modifyable attributes.
>>
>> No, I didn't mean that it is more correct to have an attribute as 
>> read-only. I meant that letting a logical data attribute start out as 
>> a read only property can help to ensure correctness.
> 
> Which is the same thing said with other words.

No, it's two different things.

Whether something is correct or not, it can help to ensure correctness.

For a different example of that, a formally incorrect debug thing can help to 
ensure correctness.


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

Hence your conclusion is wrong. :-)


> - if you 
> change semantics of something, code might break.

Yes, but that's totally out of the blue. If you, say, paint your nose bright 
green, then people might stare at it. That has nothing to do do with anything 
discussed here, and so anyone mentioning that as purportedly relevant to 
anything discussed here, would implicitly be saying "I don't understand anything 
abour it", and that's effectively what you're saying, sorry.

However, I do understand what got you confused.

Changing the internal representation of a class is not to change the class' 
semantics. It belongs to the class only. Anyone availing himself or herself of 
access to that internal representation is doing something that may or may not 
work in the future and would ideally be doing it at own's risk, but as the 
example above illustrated, they're most often doing it at *other*'s risk.

And so the issue is how to get them to not do it, even when they think that 
nobody will check their code until next version of Lib XYZ comes in a year...

And that's where using properties from the start enters the picture, making it 
less convenient for those tinkerers to use internal representation details.


> In Python, attributes 
> are part of the public interface as long as you don't explicitly define 
> them otherwise.

Not sure what that refers to.


> But preliminary assumptions about what could be in some yet unseen 
> future is introducing more code with more chances of errors

No not really.


>, reducing 
> the flexibility at the same time. I still fail to see where that's good.

Yes.

Consider the *nix convention for files, that they're just byte streams. They're 
*restricted* to byte streams. That's darn inflexible, yes?

And totally ungood. :-)  (Note: irony)


> Code for what you need code for. It works - in all languages, but 
> especially in Python.

Whether that's good advice depends on what you're doing and in what kind of job 
setting you're doing it. For many cases it is, in essence, a very selfish way. 
It gets down to saving time *now* for increased future maintainance times for 
others, which of course is the only rational choice /if/ one is sure to get away 
with it. OK, I'm not antirely serious but it sounds like you're thinking in this 
way, to some degree. But check out any debate on Python vs. Perl, in particular 
about maintainability.


Cheers & hth.,

- Alf