| |
 | Posted by Steve Schveighoffer |  Permalink Reply |
|
Steve Schveighoffer 
|
--- On Thu, 6/24/10, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 06/24/2010 11:11 AM, Steve
> Schveighoffer wrote:
> > In defense of @property, I think we all agree we
> needed something to
> > distinguish setters from single-arg functions. I
> think with a
> > reasonable rule, we can allow calling no-arg functions
> without parens
> > (via a proposal I made earlier that as long as the
> function returns
> > void, it should be allowed).
>
> Fine, though that leaves writeln = 5; on the table.
No, those are single arg functions. We need to distinguish those from property setters. @property fits the bill well. I was merely pointing out that the need for that particular aspect of @property should be obvious, and as far as I know is uncontested.
What the calling no-arg functions without parentheses allows are things like:
range.popFront;
Where popFront cannot possibly be misinterpreted as a property because it does not return a value.
>
> > All that's left is actual property
> > getters. I can't say enough that @property in
> those cases has
> > nothing to do with functionality and everything to do
> with human
> > interpretation. Like it or not, the use of
> parentheses is an
> > extension of the function name, whose semantic meaning
> of course is
> > unenforceable. But just allowing the user to
> decide whether
> > something is a property or a function leaves the
> interpretation up to
> > the user, taking all the power away from the author
> who wrote the
> > function. @property is a clarification tool, and
> by necessity, is
> > implemented via convention rather than compiler
> enforcement.
>
> I've heard this argument before. I acknowledge there is a need to address unpleasant corner cases such as functions that return functions or delegates. What I'm saying is that the feature as designed hurts most for the benefit of a couple tiny corner cases. I've seen that several times in several language before. It's called bad design.
That is not my point at all. Returning delegates from properties is a small problem compared to the one of name misinterpretation.
>
> What I'm seeing in the field after faithfully using @property for a while fits my worst predictions:
>
> 1. Code is sprinkled with @property so there's more syntactic noise to introduce and to deal with;
This is a non-argument. Whatever is decided would certainly have to be "parsed" whether it was a comment saying "this is a property" or applying @property.
> 2. Whenever I define some function I need to make an arbitrary decision whether that will be a @property or not. Reasonable people could ask me why I chose whichever way I chose. (Most recent example: save() for forward ranges.) Arbitrary decisions are bad.
In the same *exact* way, reasonable people can also question how you name functions (I personally don't like the name save for that function, it seems like you are saving something on the range, not "give me a copy of this range"). Applying @property is a convention, just like camelCase, and there is no right or wrong way to do it. Allowing people to optionally use or omit parentheses is the equivalent of users wishing to call your functions with their own preferences for casing. It leads to confusion for others who don't use that same convention. However, if you must declare the convention up front, there is no way around it -- you MUST use the author's convention, like it or not. This leads to some grumbling, but mostly comprehension and consistency.
> @property is badly designed, no two ways about it. I now regret I didn't lobby more against it. I have a similar regret about lazy.
I disagree on @property. Completely. I have no opinion on lazy, I don't really use it too much or see the problems with it.
-Steve
|
