On 2011-03-05 18:42:26 -0500, dsimcha <[email protected]> said:
This is an extreme corner case, especially if a one-way semantic
@property syntax is available to work around it. The percentage of
functions that return callables is very small, and of these the
percentage that would forget @property is probably very small. I'd
rather bug-proneness in a ridiculous corner case than breaking tons of
existing code code and losing a nice feature in the common case.
The percentage of functions that return a callable is very small until
you go to template land. I can easily make a container or a range of
delegates, and if someone somewhere forgot to make 'front' a property
in the container, in the container's range or in one of the filter
range layered on top of it, then writing 'front()' to call the front
delegate becomes unreliable. Is it a corner case? Yes. Is it ridiculous
to expect the language to detect rare but hard to find bugs? No. Is it
worth it in this case? I think so.
That said, () being optional doesn't help you use setters with chaining.
You'd have to not label your setters with @property for them to work
with chaining, unless you want to play with a lot of nested parenthesis.
(((Graph().title = abc).xTitle = def).yTitle = hij);
Wow, that looks almost like Objective-C!
Right. The point is that I can do the same thing with either property
syntax or with chaining. The choice is up to me as the caller, if the
API designer is ok with allowing this choice.
Allowing optional '()' and allowing optional '=' are two different
things. But contrary to optional '()' I don't see much of a problem
with '=' as there's no ambiguity possible. It just looks a little
strange to have a @property attribute and not restrict the property
assignment syntax to it.
--
Michel Fortin
[email protected]
http://michelf.com/
