On 12/11/2011 11:24 PM, Jonathan M Davis wrote:
On Sunday, December 11, 2011 14:54:27 Tobias Pankrath wrote:
Specifically:
"Properties should behave as if they are fields; if the method cannot,
it should not be changed to a property.
Methods are better than properties in the following situations:
- Calling the method two times in succession creates different results.
- The method performs a time-consuming operation. The method is
perceivably slower than the time that is required to set or get the
value of a field."
Since both of these can be true for all but the most trivial kinds of
ranges (e.g. file-system-related enumerators/ranges would very likely
need to re-open a handle to a directory in order to traverse it, which
is both relatively time-consuming AND returns a different result every
time, and could even unexpectedly fail due to permission/connectivity
issues), I don't think it makes sense for save() to be a @property.
I agree.
It was debated some time ago, and it ended up being a property. The fact that
save is an action verb and not a noun automatically disqualifies it as a
property IMHO, but it was made into a property, and we're pretty much stuck
with it at some point. As far as what the function does, I don't think that
it's a problem that it's a property, but it's not named like a property, so
the situation with regards to save is not ideal, but it's too late now.
- Jonathan M Davis
Reminds me of .NET's Object.GetHashCode() method, which should be a
property according to their guide. Another is Object.GetType() - why is
it not a property anyway? Both are supposed to return the same value on
succesive calls and both are computationally cheap.
Other examples are widget size setters that can be computationally quite
expensive (resizing child widgets, etc.). They are usually property
setters regardless of the fact that they are "perceivably slower" to set
than fields.
