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