byKey and byValue: properties or methods?

Steven Schveighoffer schveiguy at yahoo.com
Wed Jan 18 05:44:18 PST 2012


On Tue, 17 Jan 2012 18:29:11 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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.

The solution is easy, just don't start the discussion.  Make a decision  
(property or no), and that's the end of it.  My intuition says that you  
will purposely make the *wrong* choice just to try and get others to  
complain so you can "be right".

The point of required property semantics is that the name of the function  
includes whether you need parentheses or not.  a.empty does not have the  
same tone as a.empty().  The former looks like a field, the latter looks  
like an action.  It's a subtle bikeshed issue, but so is naming functions  
anyways!  If you think the names of things aren't important, name them  
whatever you want, but at least you as the author get to choose instead of  
the user.

And if I may add my opinion, byValue and byKey are properties.

>> 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.

I think you misunderstand Peter, he is saying we should not have  
properties *at all* a-la Java.

>> 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.

Don't forget my suggestion that void-returning no-arg functions should be  
able to be called without parens.  There should be no ambiguity (since you  
can't use it as an accessor).

But I think enforced properties is the right path, which gives all the  
naming power to the code author, not the code user.

-Steve


More information about the Digitalmars-d mailing list