October 13, 2010
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
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
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
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
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
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.
1 2 3
Next ›   Last »