Jump to page: 1 214  
Page
Thread overview
byKey and byValue: properties or methods?
Jan 17, 2012
Mail Mantis
Jan 17, 2012
Nick Sabalausky
Jan 17, 2012
Nick Sabalausky
Jan 17, 2012
Jonathan M Davis
Jan 17, 2012
Nick Sabalausky
Jan 17, 2012
Timon Gehr
Jan 18, 2012
Jacob Carlborg
Jan 17, 2012
Jonathan M Davis
Jan 17, 2012
Nick Sabalausky
Jan 17, 2012
Timon Gehr
Jan 17, 2012
Michel Fortin
Jan 17, 2012
bearophile
Jan 17, 2012
bearophile
Jan 17, 2012
Alvaro
Jan 17, 2012
Timon Gehr
Jan 17, 2012
Alvaro
Jan 17, 2012
bearophile
Jan 18, 2012
Nick Sabalausky
Jan 18, 2012
deadalnix
Jan 18, 2012
bearophile
Jan 17, 2012
Simen Kjærås
Jan 17, 2012
Timon Gehr
Jan 17, 2012
Jonathan M Davis
Jan 17, 2012
Timon Gehr
Jan 17, 2012
Jonathan M Davis
Jan 17, 2012
Peter Alexander
Jan 18, 2012
Jonathan M Davis
Jan 19, 2012
Ary Manzana
Jan 18, 2012
Nick Sabalausky
Jan 18, 2012
Nick Sabalausky
Jan 18, 2012
bearophile
Jan 18, 2012
Jonathan M Davis
Jan 18, 2012
bearophile
Jan 18, 2012
Timon Gehr
Jan 19, 2012
Peter Alexander
Jan 19, 2012
Timon Gehr
Jan 19, 2012
Jonathan M Davis
Jan 19, 2012
Timon Gehr
Jan 19, 2012
Jonathan M Davis
Jan 19, 2012
Timon Gehr
Jan 19, 2012
Peter Alexander
Jan 19, 2012
Timon Gehr
Jan 19, 2012
Jonathan M Davis
Jan 18, 2012
Jonathan M Davis
Jan 18, 2012
sclytrack
Jan 18, 2012
Jacob Carlborg
Jan 18, 2012
Jacob Carlborg
Jan 18, 2012
Nick Sabalausky
Jan 18, 2012
Nick Sabalausky
Feb 05, 2012
Alvaro
Jan 18, 2012
Manfred Nowak
Jan 19, 2012
Jacob Carlborg
Jan 17, 2012
sclytrack
Jan 17, 2012
Somedude
Jan 17, 2012
Peter Alexander
Jan 18, 2012
Martin Nowak
Jan 18, 2012
Jonathan M Davis
Jan 17, 2012
bearophile
Jan 18, 2012
bearophile
Jan 18, 2012
Kapps
Jan 18, 2012
Olivier Pisano
Jan 19, 2012
torhu
Jan 19, 2012
torhu
Jan 19, 2012
torhu
Jan 19, 2012
Jonathan M Davis
Jan 19, 2012
Marco Leise
Jan 19, 2012
Jonathan M Davis
Jan 20, 2012
Marco Leise
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
Alvaro
Jan 20, 2012
Jonathan M Davis
Jan 19, 2012
torhu
Jan 19, 2012
Jonathan M Davis
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
Johannes Pfau
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
Peter Alexander
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
Jens Mueller
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
Jens Mueller
Jan 20, 2012
Jonathan M Davis
Jan 20, 2012
Matt Soucy
Jan 20, 2012
sclytrack
Jan 20, 2012
bearophile
Jan 20, 2012
Peter Alexander
Jan 21, 2012
Michel Fortin
Jan 21, 2012
Michel Fortin
Jan 22, 2012
Alvaro
Jan 22, 2012
Jonathan M Davis
Jan 21, 2012
Johannes Pfau
Jan 21, 2012
Peter Alexander
Jan 21, 2012
torhu
Jan 21, 2012
Alix Pexton
Jan 22, 2012
Alvaro
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