January 20, 2012
El 20/01/2012 10:15, Jonathan M Davis escribió:
> On Friday, January 20, 2012 09:58:42 Marco Leise wrote:
>> Ah, I meant to say that getters should not modify their object. When I see
>> "a = abc.x[i]" I would be a little surprised to find that it changes the
>> observable state of abc. The same goes for "a = b.length()". Now it is
>> clearer, isn't is? :p
> The one major place where you essentially have a getter being able to modifer
> the original through its return value in C++ that I'm aware of is the
> subscript operator, and it has to in order to function like the built-in
> substript operator, so that's a special case.
>
> - Jonathan M Davis

Well, there is the case of std::map and its [] operator which adds an element if it does not exist. Even if in the right hand side:

a = map[x]; // modifies map if x was not found in it

Maybe Marco is talking about something like that.
January 20, 2012
On Friday, January 20, 2012 15:13:51 Alvaro wrote:
> Well, there is the case of std::map and its [] operator which adds an element if it does not exist. Even if in the right hand side:
> 
> a = map[x]; // modifies map if x was not found in it
> 
> Maybe Marco is talking about something like that.

Maybe. It's certainly a pretty horrible design decision IMHO, and it's not something that should be emulated.

- Jonathan M Davis
January 20, 2012
On Fri, 20 Jan 2012 04:29:12 -0500, Peter Alexander <peter.alexander.au@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@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.
>>
>> 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
January 20, 2012
On 1/17/12 12:48 AM, Andrei Alexandrescu wrote:
> I hate I must ask this:
>
> int[string] aa;
> foreach (k; aa.byKey) { ... }
>
> or
>
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
>
>
>
> Thanks,
>
> Andrei "I told you" Alexandrescu

I tallied the votes.

Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary Manzana, torhu.

Property: Nick Sabalausky, Simen Kjaeraas.

I wasn't able to discern a clear vote from the others. Please correct the list.


Thanks,

Andrei
January 20, 2012
On Fri, 20 Jan 2012 12:58:28 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/17/12 12:48 AM, Andrei Alexandrescu wrote:
>> I hate I must ask this:
>>
>> int[string] aa;
>> foreach (k; aa.byKey) { ... }
>>
>> or
>>
>> int[string] aa;
>> foreach (k; aa.byKey()) { ... }
>>
>>
>>
>> Thanks,
>>
>> Andrei "I told you" Alexandrescu
>
> I tallied the votes.
>
> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary Manzana, torhu.
>
> Property: Nick Sabalausky, Simen Kjaeraas.
>
> I wasn't able to discern a clear vote from the others. Please correct the list.

I voted property, though not as a direct reply before.

-Steve
January 20, 2012
On Friday, January 20, 2012 11:58:28 Andrei Alexandrescu wrote:
> On 1/17/12 12:48 AM, Andrei Alexandrescu wrote:
> > I hate I must ask this:
> > 
> > int[string] aa;
> > foreach (k; aa.byKey) { ... }
> > 
> > or
> > 
> > int[string] aa;
> > foreach (k; aa.byKey()) { ... }
> > 
> > 
> > 
> > Thanks,
> > 
> > Andrei "I told you" Alexandrescu
> 
> I tallied the votes.
> 
> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary Manzana, torhu.
> 
> Property: Nick Sabalausky, Simen Kjaeraas.
> 
> I wasn't able to discern a clear vote from the others. Please correct the list.

I'm divided. If it were keys and values, I'd be all for property, but byValue and byKey are weird property names. Of course, they're weird function names too. I assume that they essentially stand for iterateByValue and iterateByKey, which would be more of a function name, but they don't really iterate. Rather, they return something which you can iterate over.

So, from a usage perspective, it definitely makes more sense as a property, but from a naming perspective, it's a bit off. I don't really have a better suggestion though, since values and keys are already taken. So, I'm fine with it either way. There's going to be something weird about it regardless.

- Jonathan M Davis
January 20, 2012
On 01/20/2012 01:43 PM, Jonathan M Davis wrote:
> On Friday, January 20, 2012 11:58:28 Andrei Alexandrescu wrote:
>> On 1/17/12 12:48 AM, Andrei Alexandrescu wrote:
>>> I hate I must ask this:
>>>
>>> int[string] aa;
>>> foreach (k; aa.byKey) { ... }
>>>
>>> or
>>>
>>> int[string] aa;
>>> foreach (k; aa.byKey()) { ... }
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Andrei "I told you" Alexandrescu
>>
>> I tallied the votes.
>>
>> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary
>> Manzana, torhu.
>>
>> Property: Nick Sabalausky, Simen Kjaeraas.
>>
>> I wasn't able to discern a clear vote from the others. Please correct
>> the list.
>
> I'm divided. If it were keys and values, I'd be all for property, but byValue
> and byKey are weird property names. Of course, they're weird function names
> too. I assume that they essentially stand for iterateByValue and iterateByKey,
> which would be more of a function name, but they don't really iterate. Rather,
> they return something which you can iterate over.
>
> So, from a usage perspective, it definitely makes more sense as a property, but
> from a naming perspective, it's a bit off. I don't really have a better
> suggestion though, since values and keys are already taken. So, I'm fine with
> it either way. There's going to be something weird about it regardless.
>
> - Jonathan M Davis
Agreed - if it were keys and values, property would be perfect. The names themselves are a bit weird, though.
+1 Property
January 20, 2012
On 01/20/2012 06:58 PM, Andrei Alexandrescu wrote:
> On 1/17/12 12:48 AM, Andrei Alexandrescu wrote:
>> I hate I must ask this:
>>
>> int[string] aa;
>> foreach (k; aa.byKey) { ... }
>>
>> or
>>
>> int[string] aa;
>> foreach (k; aa.byKey()) { ... }
>>
>>
>>
>> Thanks,
>>
>> Andrei "I told you" Alexandrescu
>
> I tallied the votes.
>
> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary
> Manzana, torhu,
  sclytrack
>
> Property: Nick Sabalausky, Simen Kjaeraas.
>
> I wasn't able to discern a clear vote from the others. Please correct
> the list.
>
>
> Thanks,
>
> Andrei


Collection properties should satisfy the "torhu" criteria.

Collection property. Usually indexed.

Conditions:

1) The focus is on collection
2) torhu criteria

I know strings can be seen as a collection of chars.
Is string a collection or not, that's another vote.



Memory aid: torhu criteria

---
auto k = aa.byKey;
writeln(k.front);
k.popFront();
writeln(k.front);
---

to this:

---
writeln(aa.byKey.front);
aa.byKey.popFront();
writeln(aa.byKey.front);






January 20, 2012
Andrei Alexandrescu:

> I tallied the votes.
> 
> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary Manzana, torhu.
> 
> Property: Nick Sabalausky, Simen Kjaeraas.
> 
> I wasn't able to discern a clear vote from the others. Please correct the list.

I vote for byKey and byValue to be properties.

Bye,
bearophile
January 20, 2012
On 20/01/12 5:58 PM, Andrei Alexandrescu wrote:
> I tallied the votes.
>
> Function: Mail Mantis, bearophile, Jacob Carlborg, Olivier Pisano, Ary
> Manzana, torhu.
>
> Property: Nick Sabalausky, Simen Kjaeraas.
>
> I wasn't able to discern a clear vote from the others. Please correct
> the list.

I vote function.