byKey and byValue: properties or methods?

[Steven Schveighoffer]

On Fri, 20 Jan 2012 04:29:12 -0500, Peter Alexander  
<peter.alexander.au at gmail.com> wrote:

> On 20/01/12 12:57 AM, Steven Schveighoffer wrote:
>> On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no at spam.invalid> wrote:
>>>>> If the type of byKeys is Range, I would expect to be able to treat it
>>>>> like one. Not like one, then another, then another, then another...  
>>>>> ad
>>>>> infinitum.
>>>>
>>>> I don't know what you mean. You can treat it like one.
>>>>
>>>> -Steve
>>>
>>> It's the rvalue aspect. byKey does not hold a range inside the
>>> hashtable (as a member variable would do). Each use of byKey gives you
>>> a range that you get to iterate from the beginning.
>>
>> The point of a property is to allow for read-only access on something
>> that is logically a property but can only be implemented via a function.
>> byKeys is such a property. There is no way to specify a field that
>> behaves the same. This doesn't make properties invalid or useless.
>
> Can you define what "is logically a property means"? (I assume you meant  
> "field" there)

No, I meant property.  A property is a more general term.  It's a piece of  
data that is associated with an entity.  For example, if you have a ball,  
you might say that the ball is red, or it's bouncy.  Those are  
properties.  In this context (of programming language properties), a  
property can also be a piece of the entity.  For example, the valve stem  
in the ball.

properties do several things:

1. they allow you to avoid storing logically derived data.  For example,  
if I have x and y, and I want to get z = sqrt(x*x + y*y), then I could  
either store z as a field, and update it every time x and y are changed,  
or I can just make a property, which logically acts like a read-only field.
2. they allow encapsulation.  This means, I can give you information or  
mutable pieces of data from an object without actually exposing the data  
to you directly.
3. They allow you to control read/write access to a piece of data,  
including using contracts to check for errors.

byKey is an example of the first -- it's not directly stored, but is  
generated on request.  Since it's not actually stored in the object, the  
other 2 features don't apply.  Which is why I was confused as to the  
nature of the argument above, it's a derived piece of data.  The very  
nature of calculated properties are that you don't get direct access to  
the internal data because it doesn't exist!

-Steve