January 17, 2012
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
January 17, 2012
2012/1/17 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
> I hate I must ask this:

Can't find any arguments for either version, but subjectively I like non-property version more.
January 17, 2012
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jf35jr$e2k$1@digitalmars.com...
>I hate I must ask this:
>
> int[string] aa;
> foreach (k; aa.byKey) { ... }
>
> or
>
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
>

Property. It's not an action, you're just accessing a particular interface of aa.


January 17, 2012
"Nick Sabalausky" <a@a.a> wrote in message news:jf36tf$g3g$1@digitalmars.com...
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jf35jr$e2k$1@digitalmars.com...
>>I hate I must ask this:
>>
>> int[string] aa;
>> foreach (k; aa.byKey) { ... }
>>
>> or
>>
>> int[string] aa;
>> foreach (k; aa.byKey()) { ... }
>>
>
> Property. It's not an action, you're just accessing a particular interface of aa.
>

Another way you can look at it to make it clear: As far as the caller is concerened, it would have made equal sense if byKey were implemented as a nested struct. Ie, it's data, not action. Just because your implementation happens to involve an imperative block of statements doesn't change the user's perspective of byKey's semantics.

Nick "Yes, it is still clear-cut" Sabalausky ;)


January 17, 2012
On 17-01-2012 07:48, 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

My thoughts:

The "by" in the name is way too awkward for a property. If it was just named "keys" and "values", it would've been perfectly fine to make them properties, but the "by" just looks awkward when you "call" them as properties.

As far as efficiency goes, I don't think these perform any work that is heavy enough to warrant not making them properties. (I can't say that same for .dup/.idup... I still don't get why those are properties, at all.)

-- 
- Alex
January 17, 2012
On Tuesday, January 17, 2012 09:07:04 Alex Rønne Petersen wrote:
> On 17-01-2012 07:48, 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
> 
> My thoughts:
> 
> The "by" in the name is way too awkward for a property. If it was just named "keys" and "values", it would've been perfectly fine to make them properties, but the "by" just looks awkward when you "call" them as properties.
> 
> As far as efficiency goes, I don't think these perform any work that is
> heavy enough to warrant not making them properties. (I can't say that
> same for .dup/.idup... I still don't get why those are properties, at all.)

Agreed. If it were keys and values, then a property would make sense. However, since it's byKey and byValue, I don't think that it makes as much sense. It _is_ a bit of a weird case though, since byKey and byValue are neither nouns nor verbs.

- Jonathan M Davis
January 17, 2012
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.496.1326793835.16222.digitalmars-d@puremagic.com...
>On Tuesday, January 17, 2012 09:07:04 Alex Rønne Petersen wrote:
>> On 17-01-2012 07:48, Andrei Alexandrescu wrote:
>> > I hate I must ask this:
>> >
>> > int[string] aa;
>> > foreach (k; aa.byKey) { ... }
>> >
>> > or
>> >
>> > int[string] aa;
>> > foreach (k; aa.byKey()) { ... }
>> >
>>
>> The "by" in the name is way too awkward for a property. If it was just named "keys" and "values", it would've been perfectly fine to make them properties, but the "by" just looks awkward when you "call" them as properties.
>>
>> As far as efficiency goes, I don't think these perform any work that is heavy enough to warrant not making them properties. (I can't say that same for .dup/.idup... I still don't get why those are properties, at all.)
>
>Agreed. If it were keys and values, then a property would make sense.
>However,
>since it's byKey and byValue, I don't think that it makes as much sense. It
>_is_ a bit of a weird case though, since byKey and byValue are neither
>nouns
>nor verbs.
>

You're all getting hung up on the trivial detail of the names. Look at the semantics: They retreive a range associated with the aa, right? Right. Property. It's a plain old classic getter.


January 17, 2012
On 17-01-2012 13:41, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
> news:mailman.496.1326793835.16222.digitalmars-d@puremagic.com...
>> On Tuesday, January 17, 2012 09:07:04 Alex Rønne Petersen wrote:
>>> On 17-01-2012 07:48, Andrei Alexandrescu wrote:
>>>> I hate I must ask this:
>>>>
>>>> int[string] aa;
>>>> foreach (k; aa.byKey) { ... }
>>>>
>>>> or
>>>>
>>>> int[string] aa;
>>>> foreach (k; aa.byKey()) { ... }
>>>>
>>>
>>> The "by" in the name is way too awkward for a property. If it was just
>>> named "keys" and "values", it would've been perfectly fine to make them
>>> properties, but the "by" just looks awkward when you "call" them as
>>> properties.
>>>
>>> As far as efficiency goes, I don't think these perform any work that is
>>> heavy enough to warrant not making them properties. (I can't say that
>>> same for .dup/.idup... I still don't get why those are properties, at
>>> all.)
>>
>> Agreed. If it were keys and values, then a property would make sense.
>> However,
>> since it's byKey and byValue, I don't think that it makes as much sense. It
>> _is_ a bit of a weird case though, since byKey and byValue are neither
>> nouns
>> nor verbs.
>>
>
> You're all getting hung up on the trivial detail of the names. Look at the
> semantics: They retreive a range associated with the aa, right? Right.
> Property. It's a plain old classic getter.
>
>

That doesn't make the name any less bad. Naming is important IMHO. Hence why I'm also complaining about .dup/.idup.

-- 
- Alex
January 17, 2012
On Tue, Jan 17, 2012 at 4:48 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> I hate I must ask this:
>
> int[string] aa;
> foreach (k; aa.byKey) { ... }
>
> or
>
> int[string] aa;
> foreach (k; aa.byKey()) { ... }
>

If it is any help, Scala libraries use by convention that methods that have a side should be called with '()' while methods that don't have a side effect should be called without the '()'. In scala this translate to:

aa.sideEffectWhenCalled()

aa.noSideEffect

which looks as follow in the definition:

def sideEffectWhenCalled() = { ... }

def noSideEffect = { ... }

I think that this translate really well to D's property. Photos can try to implement the policy that read properties shouldn't have side effects (externally observable side effect). The language doesn't need to enforce but it would be nice if Photos would follow it.

Thoughts? Thanks,
-Jose

>
>
> Thanks,
>
> Andrei "I told you" Alexandrescu
January 17, 2012
On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> I hate I must ask this:
> 
> int[string] aa;
> foreach (k; aa.byKey) { ... }
> 
> or
> 
> int[string] aa;
> foreach (k; aa.byKey()) { ... }

Is it a verb? If not, it is a property.

But why "by"? Why not just "aa.keys"? It's much more natural. Is "byKey" going to consume the associative array like "byLine" does for files? Obviously no. So I don't see why you need "by" here.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home