View mode: basic / threaded / horizontal-split · Log in · Help
January 20, 2012
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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
Re: byKey and byValue: properties or methods?
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.
8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home