Plot2kill 0.2

[Michel Fortin]

On 2011-03-05 18:42:26 -0500, dsimcha <dsimcha at yahoo.com> 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
michel.fortin at michelf.com
http://michelf.com/