byKey and byValue: properties or methods?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Jan 17 15:29:11 PST 2012


On 1/17/12 5:13 PM, Peter Alexander wrote:
> On 17/01/12 10:11 PM, Jonathan M Davis wrote:
>> You would need to come up with some really solid arguments why it
>> should be
>> thrown out (and what we should do instead) and get both Walter and
>> Andrei (if
>> not the community at large) to agree that they not only prefer your
>> proposal
>> but that it's worth the issues that the changes are going to cause at
>> this
>> stage.
>
> There's a few good reasons to throw it out:
>
> 1. Avoids pointless discussions like this one. These discussions add
> nothing, it's just mindless bike shedding.

Yes.

> 2. The -property flag *creates* a new kind of error, but doesn't
> actually help find real problems with your code. Without properties,
> member function access would always be a.b(), and this artificial error
> could be avoided.

Yes! I can't believe we have a check that has _zero_ contribution to 
improving code.

> 3. Properties introduce another thing to remember, with no value ("was
> it byKeys, or byKeys()?"). Without properties, it would be byKeys(). No
> need to remember.

YES!!!

> 4. Properties obfuscate code. Is (a.b = c) a variable assignment or
> arbitrary function call? Who knows! Is a.b an actual variable? Can I
> write &a.b to get its address, or is it a function masquerading as a
> variable?

Hm, actually that's not bad.

> 5. One less language feature to implement, learn, document, debug, and
> discuss.

Back to yes.

> Is it practical or realistic to throw it out at this stage? I don't
> know. But there are reasons to.

Me neither. If I had my way I'd carefully redo the feature to only 
require @property on rare cases that would otherwise be ambiguous, and 
make parens optional everywhere else.


Andrei


More information about the Digitalmars-d mailing list