Fixing const arrays

[Max Samukha]

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.