On Tue, 17 Jan 2012 13:41:07 -0500, Timon Gehr <[email protected]> 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.
I think the compiler should not be in the business of generating methods
or properties that could be trivially handled by the library.
The only array-specific properties of an array that the compiler should
worry about are ptr and length. Everything else should be a library
function.
-Steve
