Uniform Function Call syntax for properties

[Robert Jacques]

On Thu, 14 Oct 2010 09:42:34 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> 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

First, to avoid confusion, I'd like to separate inappropriate usage at the  
binary level from textual/syntax level. For example, casting, compile-time  
reflection and .tupleof are all ways to circumvent the fundamental  
restrictions of a library in order to achieve inappropriate binary access,  
while alias and 'with()' allow (harmless?) syntactical changes, changing a  
library's effective API. The decision between what is and isn't  
inappropriate syntax is generally made by either the language designer or  
by your project's style guide. Indeed, libraries that define extensive  
changes in a language's appropriate syntax are often referred to as being  
domain specific languages instead of a simple libraries, modules or  
packages. And part of the reason for this nomenclature change is that  
DSLs, unlike libraries, tend to compose poorly and require varying levels  
of programmer buy-in. This is one reason why none of the DSL/macro  
features implemented and/or proposed for D are pervasive; they all have a  
very specific and defined radius of comprehension and scope.

Which brings us to the concept of methods behaving syntactically as  
fields. The three solutions put forth so far are: methods-as-properties,  
which allow methods to behave like methods or fields; @property, which  
force specific methods to behave only as fields; and the uniform access  
principle, which allows methods _and_ fields to behave like either methods  
or fields. Both MAP and UAP are language level syntax changes, while  
@property gives libraries pervasive DSL-lite abilities. The main  
advantages of MAP and UAP is that they allow the project team to better  
select a coding style that suites them. On the downside, neither MAP nor  
UAP are mainstream concepts, so it can take people time to adapt, and more  
coding style choice inevitably breeds more coding style wars (i.e.  
names_with_underscores vs CamelCase, csHangarian vbNotation, sVNs vs  
longVariableNames, etc.). @property, on the other hand, moves the coding  
style choice to the library author, which, on the plus side, is similar to  
how C# handles things. However, it forces the author to choose a single  
coding style, which may not be appropriate for all users for all time.  
(read: poor user buy-in) Worse, an author's style choice will enviably  
conflict with either the project's style guidelines or a second author's  
library, leading to user code which has to constantly change styles.  
(read: poor composition) And the composition problem only worsens for  
generic code.

I fully agree that the ability to define the acceptable syntactic usage is  
critical to avoiding confusion, I simply believe that putting that  
responsibility in that hands of a project's style guide provides the best  
consistency and is the most inclusive. Furthermore, I would point out that  
ultimately the author serves the user; they are his/her customer and good  
libraries don't unnecessarily restrict their users. Indeed, one of D's  
best feature is the collection of things, both great and small, that lets  
it get out of the way of the coding process.

BTW: That article on the uniform access principal has an interesting  
sidebar on how Eiffel satisfied two very different sets of programmers who  
desired mutually exclusive syntaxes.  
(http://www.eiffel.com/general/column/2005/Sept_October.html)