@property

Pelle pelle.mansson at gmail.com
Thu Jun 24 15:24:55 PDT 2010


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.

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.

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.


More information about the Digitalmars-d mailing list