Uniform Function Call syntax for properties

[Robert Jacques]

On Thu, 14 Oct 2010 22:22:19 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 14 Oct 2010 20:28:45 -0400, Robert Jacques <sandford at jhu.edu>  
> wrote:
>>
>> 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.
>
> as well you can rename anything you want.  Hell, for most D projects you  
> have the source, just rename it!
>
> But if you want your code to be readable, you should follow the  
> convention that the author intended, because that's how everyone else  
> will read it and understand it.
>
>>
>> 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.
>
> Couldn't disagree more.  An API without appropriate function names ==  
> fail.  And the call style is part of the function name, like it or not.   
> People see x = y, they think field.  People see x(y) they think  
> function.  No matter the camel casing, or spacing between parentheses,  
> or prefixes to the function name, or whether the curly brace is on the  
> next line or not.  It amazes me how many times we have to go over this.
>
>>
>> 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.
>
> I want the *compiler* to tell me when I incorrectly used a property, not  
> a style guide (which requires a person for interpretation).
>
> -Steve

I think you have misunderstood something. It is partly my fault, as I used  
naming styles as an example. More pertinent examples would be function  
calls vs operator overloading, or prefix (= x y) vs infix (x = y) vs  
postfix (x y =) notation. These are issues which are normally the purview  
of the language designer. When the language designer opens up field /  
method syntax to programmer control, the assumption that x = y means  
fields ceases to be axiomatic and becomes a programming convention/style.  
Similarly, that x(y) indicates a function call can also become a  
programming convention/style. Other programming languages, for example  
Eiffel, have proven the usefulness of field/method styles other than those  
of the C-family. In fact Eiffel does not syntactically differentiate  
stored values (aka fields) from computed values (aka methods), giving it a  
slightly functional feel.

Given a method of control, be it by the Universal-Access-Principal,  
Method-as-Properties or @property, users/authors will all write code in  
their own preferred style. And although each of these styles is internally  
logical and self-consistent, unlike names_with_underscores and  
CamelCaseNames, they may violate each others internal assumptions. So,  
yes, @property allows the authors to define a compiler enforceable way to  
use a property. And that's great when your preferred style and the  
author's match. But it also means you're forced to write the equivalent of  
'writeln = 42' when your preferred style and the author's don't match.