Uniform Function Call syntax for properties

[Steven Schveighoffer]

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