January 19, 2012
On Thursday, January 19, 2012 11:33:24 Andrei Alexandrescu wrote:
> On 1/19/12 11:29 AM, torhu wrote:
> > The reason would be that if it looks like field access, it should behave like that.
> 
> The difficulty is in knowing where to stop. The only things that behaves exactly like a field access is a field access. This is a known issue in C++, e.g. smart pointers "are smart but aren't pointers".

Yeah. It's generally expected that properties may return stuff which is generated on each call. They're _simulating_ a member variable rather than being one. I don't think that the fact that a new value is returned each time is particularly relevant, especially since as long as the AA hasn't been altered, the returned values are equivalent.

- Jonathan M Davis
January 19, 2012
On 19.01.2012 19:17, Steven Schveighoffer wrote:
>
> That's like saying this:
>
> int[] arr;
>
> int l = arr.length;
> l++;
>
> should be the same as this:
>
> arr.length++;
>
> because it's a property.
>
> This is an orthogonal problem.  byKey doesn't try to affect the original
> AA, so the semantics should be the same whether you save a copy or access
> it in one line.
>
> There are no hard-fast rules on what should be properties and what
> shouldn't.  But the rvalue vs lvalue is an orthogonal problem.

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.
January 19, 2012
Am 19.01.2012, 19:19 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Thursday, January 19, 2012 11:33:24 Andrei Alexandrescu wrote:
>> On 1/19/12 11:29 AM, torhu wrote:
>> > The reason would be that if it looks like field access, it should  
>> behave
>> > like that.
>>
>> The difficulty is in knowing where to stop. The only things that behaves
>> exactly like a field access is a field access. This is a known issue in
>> C++, e.g. smart pointers "are smart but aren't pointers".
>
> Yeah. It's generally expected that properties may return stuff which is
> generated on each call. They're _simulating_ a member variable rather than
> being one. I don't think that the fact that a new value is returned each time
> is particularly relevant, especially since as long as the AA hasn't been
> altered, the returned values are equivalent.
>
> - Jonathan M Davis

I just came across some C++ code and came to the conclusion, that properties and indexed access should not modify the structure. In other words all my @property and opIndex will probably also by const. An exception to that being caching and access counting.
January 19, 2012
On Thursday, January 19, 2012 20:56:39 Marco Leise wrote:
> I just came across some C++ code and came to the conclusion, that properties and indexed access should not modify the structure. In other words all my @property and opIndex will probably also by const. An exception to that being caching and access counting.

I don't know why you came to that concluson. I don't agree at all. Obviously, you're free to do what you want with your code, but that seems overly restrictive to little or no benefit. Properties can be both getters and setters for a reason. It would be horrible if all you had were getters.

- Jonathan M Davis
January 19, 2012
On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@spam.invalid> wrote:

> On 19.01.2012 19:17, Steven Schveighoffer wrote:
>>
>> That's like saying this:
>>
>> int[] arr;
>>
>> int l = arr.length;
>> l++;
>>
>> should be the same as this:
>>
>> arr.length++;
>>
>> because it's a property.
>>
>> This is an orthogonal problem.  byKey doesn't try to affect the original
>> AA, so the semantics should be the same whether you save a copy or access
>> it in one line.
>>
>> There are no hard-fast rules on what should be properties and what
>> shouldn't.  But the rvalue vs lvalue is an orthogonal problem.
>
> 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
January 19, 2012
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@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.

Andrie
January 19, 2012
On Thursday, January 19, 2012 17:41:44 Andrei Alexandrescu wrote:
> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
> > On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@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.

Well, that's part of the point of properties. They don't have to actually be associated with any particular member variable. They just _act_ like the type has that public member variable.

- Jonathan M Davis
January 20, 2012
On 1/19/12 5:57 PM, Jonathan M Davis wrote:
> On Thursday, January 19, 2012 17:41:44 Andrei Alexandrescu wrote:
>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu<no@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.
>
> Well, that's part of the point of properties. They don't have to actually be
> associated with any particular member variable. They just _act_ like the type
> has that public member variable.

Yah, but .length acts to a better extent like an lvalue.

Andrei

January 20, 2012
On Thursday, January 19, 2012 18:07:50 Andrei Alexandrescu wrote:
> Yah, but .length acts to a better extent like an lvalue.

True, but that's because it's both a getter and a setter. What's weirder IMHO is properties which are just setters, but they do make sense once in a while.

- Jonathan M Davis
January 20, 2012
On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>
>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@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.
>
> Andrie

I think MSDN has some decent advice on when to use properties vs
methods: http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpconpropertyusageguidelinesanchor1