@property

[Steven Schveighoffer]

On Thu, 24 Jun 2010 18:24:55 -0400, Pelle <pelle.mansson at gmail.com> wrote:

> On 06/24/2010 11:38 PM, Steven Schveighoffer wrote:
>> This is why you are confused -- @property *is* a naming issue. The
>> difference between the hackish D current syntax and the sane @property
>> syntax is that in hackish D, the caller gets to decide how to name the
>> function, which doesn't make any sense.
>>
>> And the problem is precisely that it's anyone's guess. It should be up
>> to the author of the structure. It should *not* be up to the user of the
>> struct to 'guess'.
>>
>> How about we get rid of case-sensitivity, so people who like to use all
>> caps can have their say in how they call your functions. Does it make
>> any sense? How about we allow spanish translations of english terms to
>> be used? How about just unambiguous prefixes? Any naming issue should be
>> decided by the author of the function so that 1) it's consistent
>> everywhere it's used and 2) the author is free to imply a meaning
>> without resorting to overly verbose text. To allow otherwise causes way
>> more confusion than some author who can't decide on whether something is
>> a property or not. I very seldom run into cases where the name of the
>> function is obvious, but whether to make it a property or not isn't. I
>> always consider the property/no-property question when deciding the
>> name. Empty is a perfect example -- property through and through.
>>
>> Save is not as obvious, but that's because the author decided the name
>> without considering whether it should be a property. If it should be
>> considered a property, it should be a noun (not a hard rule, but it
>> makes more sense that way). I'd say something like 'copy' would look
>> better as a property. But IMO, save provides almost no utility so that
>> leads to it being hard to name. Blaming property syntax is not the way  
>> out.
>>
>
> Your argument seems to stem from the idea that @property is part of the  
> name of a function, and that the () indicates some mutative action upon  
> an object.

Not exactly.  I think () implies a function where no () implies a  
property.  Mutation is *not* implied in ().

What a function or a property consists of is all open to interpretation.   
Generally it's assumed that a getter property gets a value from the  
object, and a setter sets a value, and a function can do whatever it wants  
(mutation or otherwise).  But what should not be open to interpretation is  
whether something is a property or a function.  The key here is the  
*author* gets to decide the interpretation, so any usage of his code is  
consistent.

> Well, liking it or not I do not agree about the naming part, I see it  
> more in the league of coding style and indentation. I totally allow  
> users of my code to decide their variable names and indentation style.

This is not about allowing users to decide their variable names, it's  
about not letting users decide *your* variable names.  If I build a struct  
or class, I want it's usage to be well-defined and consistent.

> We always have constness and/or purity to imply lack of mutation.
>
> Is split a property? It doesn't mutate a string, and totally could be an  
> instance variable for every given string, but isn't. It doesn't really  
> feel property-like, but writing "a b c".split without parentheses works  
> better than with them.

I disagree, I think "a b c".split() looks better.  But it should be up to  
the author of split, if he thinks it's a property, then so be it, we will  
all use it as a property.

-Steve