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.
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 - if you
change semantics of something, code might break. In Python, attributes
are part of the public interface as long as you don't explicitly define
them otherwise.
But preliminary assumptions about what could be in some yet unseen
future is introducing more code with more chances of errors, reducing
the flexibility at the same time. I still fail to see where that's good.
Code for what you need code for. It works - in all languages, but
especially in Python.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
