November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis wrote:
> Given the fact that this subject is extremely devisive, I suspect that the
> best that we can hope for at this point is for lax property enforcement
@property shouldn't be about enforcement. This is the fundamental flaw in the -property switch. While I think you and I are talking about the same goal, this is an important distinction to make: the fix isn't syntax. It is a semantic rewrite.
After referencing a property is rewritten to be a call, the syntax will just work:
@property int foo() {}
int a = foo(); // the error here is NOT "you must not use () on properties". It is "type int is not callable"
This is something that's bothered me about the @property debate since day one: we spend all this time talking about syntax.... but that's a side effect, not the core question.
|
November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Tuesday, November 20, 2012 20:12:56 Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
>
> wrote:
> > Given the fact that this subject is extremely devisive, I
> > suspect that the
> > best that we can hope for at this point is for lax property
> > enforcement
>
> @property shouldn't be about enforcement. This is the fundamental flaw in the -property switch. While I think you and I are talking about the same goal, this is an important distinction to make: the fix isn't syntax. It is a semantic rewrite.
>
> After referencing a property is rewritten to be a call, the syntax will just work:
>
> @property int foo() {}
>
> int a = foo(); // the error here is NOT "you must not use () on
> properties". It is "type int is not callable"
>
> This is something that's bothered me about the @property debate since day one: we spend all this time talking about syntax.... but that's a side effect, not the core question.
It's the same result. @property means that the function is treated as a variable, so it doesn't make sense that parens be used. If the error treats it like a variable to the point that it complains about trying to use parens on the variable rather than the fact that you tried to use parens on an @property function, all the better.
- Jonathan M Davis
|
November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | On 11/20/2012 02:49 PM, Regan Heath wrote:
> On Tue, 20 Nov 2012 13:26:15 -0000, Adam D. Ruppe
> <destructionator@gmail.com> wrote:
>
>> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>>> Should this be allowed for functions that isn't marked with @property:
>>>
>>> foo = 3;
>>
>> Yes. We should *only* be changing the way @property is implemented.
>> (Namely, actually implementing it!)
>>
>> Don't want to break existing code. The new changes must be opt in.
>
> Usually I'd agree but this is a case of a wart we should just remove
> IMO. The fix for breaking cases is simple, add @property.
>
>> If there's both an @property setter and a regular function, the
>> property should be used here.
>
> Agreed. But it's waay clearer whats going on if @property is required
> to call functions using this syntax.
>
> R
>
Not really.
@property T front(T)(T[] arr) { return arr[0]; }
[1,2,3,4].front;
front = [1,2,3,4];
|
November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote: > On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: >> I'm not sure how it fit in the DIP but &funName is ambiguous when funName return a reference. > > We can just define this away: &funName if it isn't a @property is the address of the function. > So this is impossible to get the address of the returned reference. > If it is a @property, ALL operations work on the return value, so it is rewritten as &(funName()). I agree that this is ho it should work. |
November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 11/20/2012 09:56 PM, deadalnix wrote: > On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote: >> On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: >>> I'm not sure how it fit in the DIP but &funName is ambiguous when >>> funName return a reference. >> >> We can just define this away: &funName if it isn't a @property is the >> address of the function. >> > > So this is impossible to get the address of the returned > reference. > &funName() >> If it is a @property, ALL operations work on the return value, so it >> is rewritten as &(funName()). > > I agree that this is ho it should work. +1. |
November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Tuesday, 20 November 2012 at 19:12:58 UTC, Adam D. Ruppe wrote: > On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis wrote: >> Given the fact that this subject is extremely devisive, I suspect that the >> best that we can hope for at this point is for lax property enforcement > > @property shouldn't be about enforcement. This is the fundamental flaw in the -property switch. While I think you and I are talking about the same goal, this is an important distinction to make: the fix isn't syntax. It is a semantic rewrite. > > After referencing a property is rewritten to be a call, the syntax will just work: > > @property int foo() {} > > int a = foo(); // the error here is NOT "you must not use () on properties". It is "type int is not callable" > > Yes > > This is something that's bothered me about the @property debate since day one: we spend all this time talking about syntax.... but that's a side effect, not the core question. +1 |
November 20, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 20 November 2012 at 21:19:20 UTC, Timon Gehr wrote: > On 11/20/2012 09:56 PM, deadalnix wrote: >> On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote: >>> On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: >>>> I'm not sure how it fit in the DIP but &funName is ambiguous when >>>> funName return a reference. >>> >>> We can just define this away: &funName if it isn't a @property is the >>> address of the function. >>> >> >> So this is impossible to get the address of the returned >> reference. >> > > &funName() > So now funName and funName are not equivalent anymore. Special cases should be removed, not added. >>> If it is a @property, ALL operations work on the return value, so it >>> is rewritten as &(funName()). >> >> I agree that this is ho it should work. > > +1. |
November 21, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | Le 20/11/2012 12:18, Timon Gehr a écrit :
> On 11/20/2012 02:49 PM, Regan Heath wrote:
>> On Tue, 20 Nov 2012 13:26:15 -0000, Adam D. Ruppe
>> <destructionator@gmail.com> wrote:
>>
>>> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>>>> Should this be allowed for functions that isn't marked with @property:
>>>>
>>>> foo = 3;
>>>
>>> Yes. We should *only* be changing the way @property is implemented.
>>> (Namely, actually implementing it!)
>>>
>>> Don't want to break existing code. The new changes must be opt in.
>>
>> Usually I'd agree but this is a case of a wart we should just remove
>> IMO. The fix for breaking cases is simple, add @property.
>>
>>> If there's both an @property setter and a regular function, the
>>> property should be used here.
>>
>> Agreed. But it's waay clearer whats going on if @property is required
>> to call functions using this syntax.
>>
>> R
>>
>
> Not really.
>
> @property T front(T)(T[] arr) { return arr[0]; }
>
> [1,2,3,4].front;
>
> front = [1,2,3,4];
>
I conclude that @property should be limited to member function or UFCS calls. Otherwize, we get really weird stuffs going on.
|
November 21, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | Le 20/11/2012 04:33, Jacob Carlborg a écrit : > On 2012-11-20 08:48, thedeemon wrote: > >> This is just an old habit to see identifier with parens as a function >> call and identifier without parens as a variable, so calling functions >> without parens seem too unconventional to you. However there are many >> languages which dropped this tradition and they are known for being >> expressive and concise, that's why people love them. Recently we saw an >> article from Walter about component programming which one could say was >> really about function composition. It's really convenient to write code >> in conveyor-style, this is what we see often in functional languages, as >> well as some dynamic OO ones. For example, the task of reversing words >> in a string may look like: > > I completely agree. > >> "one two three".split.map{|s| s.reverse}.join(' ') >> in Ruby > > In this particular case you can use a shorter form of the map call: > > "one two three".split.map(&:reverse).join(' ') > >> print . unwords . map reverse . words $ "one two three" >> in Haskell >> >> "one two three" |> split " " |> List.map reverse |> String.join " " |> >> print_string >> in OCaml >> and something similar and even without dots in Scala. > > Wouldn't the Scala syntax look fairly similar to Ruby: > > "one two three".split.map(reverse).join(' ') > Note the map(reverse) and not map(&reverse) >> Ease of chaining functions together is one of the things that make those >> languages so pleasant to work with. I love to have the same in current D >> and it would be a pity to lose it due to a clash with some old-fashioned >> tradition. > > I completely agree again. > |
November 21, 2012 Re: @property needed or not needed? | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On 2012-11-21 07:55, deadalnix wrote: > Note the map(reverse) and not map(&reverse) I said "fairly similar" not "exactly the same" :) -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation