[Tutor] R: Re: Re: Re: Class learning

[Cameron Simpson]

On 24Jan2015 00:47, Alan Gauld <alan.gauld at btinternet.com> wrote:
>On 24/01/15 00:37, Cameron Simpson wrote:
>>By contrast, I use it a far bit (though still far less than non-property
>>methods).  Generally for derived properties which are:
>>  - cheap to compute i.e. O(1)
>>  - which I want to abstract
>>  - usually represent some property which is stable, such as a size
>>  - occasionally (much more rarely) a property which is not stable,
>
>But why a property rather than a simple method?
>Why is
>
>k = url.key
>
>better than
>
>k = url.key()
>
>for meeting those criteria?

Because it is a value that feels like an attribute.

A method that always returns the same value for a given object (and is very 
cheap) is, to my mind, not worth burdening the caller with the detail that is 
it a function.

If the caller can ask for o.key() and be given a value that is stable, and will 
not change (and therefore will never require another call if the caller bothers 
keeping the value around) then why should the caller care that it is a 
function? So why should it even look like a function?

It should look and feel like any other object attribute - a simple value that 
can just be examined.

My intuition is that a function is costly (potentially) and that consulting an 
attribute is very cheap.  I don't want to break such intuition.

Consider .keys() for a dynamic mapping. Changeable, and expensive. It should 
look like a function.

Cheers,
Cameron Simpson <cs at zip.com.au>

A pessimist is an optimist in full possession of the facts.