On 17-01-2012 19:41, Timon Gehr wrote:
On 01/17/2012 02:14 PM, Alex Rønne Petersen wrote:
On 17-01-2012 13:41, Nick Sabalausky wrote:
"Jonathan M Davis"<[email protected]> wrote in message
news:[email protected]...
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.
I think the compiler should just allow .dup()/.idup(). It would not
break any existing code.
+1.
--
- Alex
