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.

Reply via email to