On Thu, 24 Jun 2010 18:24:55 -0400, Pelle <[email protected]> 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
