Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
January 26, 2013 On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
While the storm raged, I decided to try implementing properties as library types. I encountered a few obstacles, which I will outline here.
First, my intended syntax:
class A {
int _n;
Property!(
() => _n,
value => _n = value
) n;
}
Property would then be a struct, with operators and functions defined as required, copying disabled, and of course alias this.
Now, the obstacle here is I can't refer to _n in those lambdas. Why not? I'm guessing the struct has no context member, and the lambdas don't because the class is not yet instantiated. Could this be fixed? I think so, and I think this is a feature with benefits beyond simple properties.
This library solution would not be able to do everything a language solution could. Amongst those, typeof(property) would return Property!(..., ...). Just as important, this would not work:
auto a = foo.property;
, because the struct's postblit is marked @disable. Perhaps alias this should be attempted in such a situation?
--
Simen
|
January 26, 2013 Re: On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | Reason why library properties are not that usable is simple: typeof(A._n) must be same as typeof(A.n) or this is not really a property. Please take a look at examples and arguments in wiki: http://wiki.dlang.org/Property_Discussion_Wrap-up |
January 26, 2013 Re: On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On Saturday, 26 January 2013 at 14:41:43 UTC, Simen Kjaeraas wrote:
> Now, the obstacle here is I can't refer to _n in those lambdas. Why not? I'm guessing the struct has no context member, and the lambdas don't because the class is not yet instantiated. Could this be fixed? I think so, and I think this is a feature with benefits beyond simple properties.
Structs inside classes do not have access to outer scope (no outer property, no context pointer). Last time it was discussed month ago. There is probably a bugzilla issue for this but it seems it would not be fixed soon, let alone there were no consensus that it should work.
|
January 26, 2013 Re: On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 01/26/2013 03:41 PM, Simen Kjaeraas wrote: > While the storm raged, I decided to try implementing properties as > library types. I encountered a few obstacles, which I will outline here. > > First, my intended syntax: > > class A { > int _n; mixin Property!( > () => _n, > value => _n = value > ) n; > } > ... http://d.puremagic.com/issues/show_bug.cgi?id=7653 |
January 26, 2013 Re: On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 2013-23-26 20:01, Timon Gehr <timon.gehr@gmx.ch> wrote: > On 01/26/2013 03:41 PM, Simen Kjaeraas wrote: >> While the storm raged, I decided to try implementing properties as >> library types. I encountered a few obstacles, which I will outline here. >> >> First, my intended syntax: >> >> class A { >> int _n; > mixin Property!( >> () => _n, >> value => _n = value >> ) n; >> } >> ... > > > http://d.puremagic.com/issues/show_bug.cgi?id=7653 And how might that work? -- Simen |
January 27, 2013 Re: On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 01/27/2013 12:23 AM, Simen Kjaeraas wrote:
> On 2013-23-26 20:01, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 01/26/2013 03:41 PM, Simen Kjaeraas wrote:
>>> While the storm raged, I decided to try implementing properties as
>>> library types. I encountered a few obstacles, which I will outline here.
>>>
>>> First, my intended syntax:
>>>
>>> class A {
>>> int _n;
>> mixin Property!(
>>> () => _n,
>>> value => _n = value
>>> ) n;
>>> }
>>> ...
>>
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=7653
>
> And how might that work?
>
>
It wouldn't work so well. I think there is no way to get what you want, because the type of a.n would need to be 'int', and so there is no way to hook in the setter.
|
January 27, 2013 Re: On the subject of properties, and possibility of having them in the library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 2013-49-27 09:01, Timon Gehr <timon.gehr@gmx.ch> wrote: > On 01/27/2013 12:23 AM, Simen Kjaeraas wrote: >> On 2013-23-26 20:01, Timon Gehr <timon.gehr@gmx.ch> wrote: >> >>> On 01/26/2013 03:41 PM, Simen Kjaeraas wrote: >>>> While the storm raged, I decided to try implementing properties as >>>> library types. I encountered a few obstacles, which I will outline here. >>>> >>>> First, my intended syntax: >>>> >>>> class A { >>>> int _n; >>> mixin Property!( >>>> () => _n, >>>> value => _n = value >>>> ) n; >>>> } >>>> ... >>> >>> >>> http://d.puremagic.com/issues/show_bug.cgi?id=7653 >> >> And how might that work? >> >> > > It wouldn't work so well. I think there is no way to get what you want, because the type of a.n would need to be 'int', and so there is no way to hook in the setter. There's an enhancement request[1] in bugzilla for operator overloading on non-type template instances. This, with opDispatch and alias this (and allowing for typeof to return the alias this'd type in this situation), would allow for properties to be a simple template. [1]: http://d.puremagic.com/issues/show_bug.cgi?id=5158 -- Simen |
Copyright © 1999-2021 by the D Language Foundation