Uniform Function Call syntax for properties

Steven Schveighoffer schveiguy at yahoo.com
Thu Oct 14 06:42:34 PDT 2010


On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>> Because then we are back to writeln = 42;
>>
>> -Steve
>
> :) I see that despite not valid code for what, over a year now?, writeln  
> = 42 still persists.

IMO, that's because the head squeaky wheel is not really fond of  
properties :)  It will eventually be fixed.

> That said, how exactly are we back to the verb = value "problem"?

Because you can use properties in ways they weren't meant to be used.   
Specifically, you can use a getter as a setter or vice versa.  I admit  
it's not exactly the same problem, but it's a very similar issue.

> The rearrangement ambiguity was never the expressed reason for  
> introducing @property. In fact, despite all the passionate posts about  
> how wrong "verb = value" looks, it took a very specific syntax ambiguity  
> with delegates/opCall to warrant language inclusion. And given the  
> practical problems @property has been running into, it kinda makes me  
> wish I had run across the uniform access principle  
> (http://www.eiffel.com/general/column/2005/Sept_October.html) back  
> during the debates.

I must have said this a hundred thousand times.  It has to do with the  
power of the author to define usage.  When you let the user define usage,  
confusion ensues.  To me, the delegate issue is a nice bonus, and if  
that's what pushed property acceptance over the edge, so be it.

Without the restrictions, the author loses the power to define usage, and  
he resorts to creating more verbose language like getFoo instead of just  
foo.  Welcome to Java.

-Steve


More information about the Digitalmars-d mailing list