byKey and byValue: properties or methods?

[Ary Manzana]

On 1/17/12 8:29 PM, Andrei Alexandrescu wrote:
> 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

Before I knew Ruby I was in favor of @property. Now I'm against it.