View mode: basic / threaded / horizontal-split · Log in · Help
October 13, 2010
Re: Uniform Function Call syntax for properties
On Sat, 09 Oct 2010 21:58:00 -0400, Robert Jacques <sandford@jhu.edu>  
wrote:

> On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2korden@gmail.com>  
> wrote:
>
>> On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly <sean@invisibleduck.org>  
>> wrote:
>>
>>> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>> On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
>>>>> Someone was asking about UFC syntax for properties on d.learn, and I
>>>>> realized, we have a huge ambiguity here.
>>>>>
>>>>> Given a function:
>>>>>
>>>>> @property int foo(int x)
>>>>>
>>>>> Is this a global setter or a getter on an int?
>>>>
>>>> Good question.
>>>
>>> Setter. Consider "a = b = c".
>>
>> I think you missed the point. Which of the two is it:
>>
>> int x = 42;
>> auto y = x.foo(); // transformed into "auto y = foo(x);", getter
>>
>> or
>>
>> foo = 42; // transformed into "foo(42);", setter
>>
>> Both match.
>
> I agree that there is ambiguity here, but does it why does foo have to  
> be only a getter or only a setter? Why can't it behave like either,  
> depending on its implementation and use?

Because then we are back to writeln = 42;

-Steve
October 14, 2010
Re: Uniform Function Call syntax for properties
On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer  
<schveiguy@yahoo.com> wrote:
> On Sat, 09 Oct 2010 21:58:00 -0400, Robert Jacques <sandford@jhu.edu>  
> wrote:
>
>> On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2korden@gmail.com>  
>> wrote:
>>
>>> On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly  
>>> <sean@invisibleduck.org> wrote:
>>>
>>>> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>>> On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
>>>>>> Someone was asking about UFC syntax for properties on d.learn, and I
>>>>>> realized, we have a huge ambiguity here.
>>>>>>
>>>>>> Given a function:
>>>>>>
>>>>>> @property int foo(int x)
>>>>>>
>>>>>> Is this a global setter or a getter on an int?
>>>>>
>>>>> Good question.
>>>>
>>>> Setter. Consider "a = b = c".
>>>
>>> I think you missed the point. Which of the two is it:
>>>
>>> int x = 42;
>>> auto y = x.foo(); // transformed into "auto y = foo(x);", getter
>>>
>>> or
>>>
>>> foo = 42; // transformed into "foo(42);", setter
>>>
>>> Both match.
>>
>> I agree that there is ambiguity here, but does it why does foo have to  
>> be only a getter or only a setter? Why can't it behave like either,  
>> depending on its implementation and use?
>
> 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.
That said, how exactly are we back to the verb = value "problem"? 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.
October 14, 2010
Re: Uniform Function Call syntax for properties
On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques <sandford@jhu.edu>  
wrote:

> On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer  
> <schveiguy@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
October 15, 2010
Re: Uniform Function Call syntax for properties
On Thu, 14 Oct 2010 09:42:34 -0400, Steven Schveighoffer  
<schveiguy@yahoo.com> wrote:

> On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques <sandford@jhu.edu>  
> wrote:
>
>> On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer  
>> <schveiguy@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)
October 15, 2010
Re: Uniform Function Call syntax for properties
On Thu, 14 Oct 2010 20:28:45 -0400, Robert Jacques <sandford@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
October 17, 2010
Re: Uniform Function Call syntax for properties
On Thu, 14 Oct 2010 22:22:19 -0400, Steven Schveighoffer  
<schveiguy@yahoo.com> wrote:

> On Thu, 14 Oct 2010 20:28:45 -0400, Robert Jacques <sandford@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.
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home