May 07, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > On 2012-05-07 21:53, Steven Schveighoffer wrote: > >> How do you overload the operator for a property? For example: It can of course be done [1], but i think the question was whether the compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'. Unconditionally, as not doing it every time would be confusing and lead to bugs where the setter gets bypassed. But what about the case where you want to return a ref to /different/ objects? I guess mandating a setter wouldn't be problem, and still better than the alternative. artur [1] I shouldn't even be posting this, as someone might actually think about using something like it... struct S { int i; @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; } } int main() { S s; s.p |= 2; return s.p; } struct PropProxy(RT, string sym) { @property ref data() { return *cast(RT*)&this; } @property ref get() { return __traits(getMember, data, sym); } alias get this; auto opOpAssign(string op, T)(T b) { return mixin("data." ~ sym ~ " " ~ op ~ "= b"); } } Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just out of curiosity, to check if GDC would be able to turn it all into "mov $0x2, %eax; ret;". ;) |
May 07, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
On 7 May 2012 23:23, Artur Skawina <art.08.09@gmail.com> wrote: >> On 2012-05-07 21:53, Steven Schveighoffer wrote: >> >>> How do you overload the operator for a property? For example: > > It can of course be done [1], but i think the question was whether the > compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'. > Unconditionally, as not doing it every time would be confusing and lead > to bugs where the setter gets bypassed. > But what about the case where you want to return a ref to /different/ > objects? I guess mandating a setter wouldn't be problem, and still better > than the alternative. > > artur > > [1] I shouldn't even be posting this, as someone might actually think about using something like it... > > struct S { > int i; > @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; } > } > > int main() > { > S s; > s.p |= 2; > return s.p; > } > > struct PropProxy(RT, string sym) { > @property ref data() { return *cast(RT*)&this; } > @property ref get() { return __traits(getMember, data, sym); } > alias get this; > auto opOpAssign(string op, T)(T b) { > return mixin("data." ~ sym ~ " " ~ op ~ "= b"); > } > } > > Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just > out of curiosity, to check if GDC would be able to turn it all into > "mov $0x2, %eax; ret;". ;) > Your wishful thinking serves you well. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; |
May 07, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
On 05/08/12 00:32, Iain Buclaw wrote:
> On 7 May 2012 23:23, Artur Skawina <art.08.09@gmail.com> wrote:
>>> On 2012-05-07 21:53, Steven Schveighoffer wrote:
>>>
>>>> How do you overload the operator for a property? For example:
>>
>> It can of course be done [1], but i think the question was whether the
>> compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'.
>> Unconditionally, as not doing it every time would be confusing and lead
>> to bugs where the setter gets bypassed.
>> But what about the case where you want to return a ref to /different/
>> objects? I guess mandating a setter wouldn't be problem, and still better
>> than the alternative.
>>
>> artur
>>
>> [1] I shouldn't even be posting this, as someone might actually think about using something like it...
>>
>> struct S {
>> int i;
>> @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; }
>> }
>>
>> int main()
>> {
>> S s;
>> s.p |= 2;
>> return s.p;
>> }
>>
>> struct PropProxy(RT, string sym) {
>> @property ref data() { return *cast(RT*)&this; }
>> @property ref get() { return __traits(getMember, data, sym); }
>> alias get this;
>> auto opOpAssign(string op, T)(T b) {
>> return mixin("data." ~ sym ~ " " ~ op ~ "= b");
>> }
>> }
>>
>> Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just
>> out of curiosity, to check if GDC would be able to turn it all into
>> "mov $0x2, %eax; ret;". ;)
>>
>
> Your wishful thinking serves you well. :-)
>
Just to make it clear - the above results in:
08049e50 <_Dmain>:
8049e50: 55 push %ebp
8049e51: b8 02 00 00 00 mov $0x2,%eax
8049e56: 89 e5 mov %esp,%ebp
8049e58: 5d pop %ebp
8049e59: c3 ret
and i believe that after Iain's recent GDC ABI changes the frame pointer manipulation is gone, so it all *really* compiles down to just one instruction. But i haven't checked with a current GDC. r748:ab99d67f04c2 generates the above asm sequence, which is good enough for this quick test, ;)
artur
|
May 07, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
On 7 May 2012 23:43, Artur Skawina <art.08.09@gmail.com> wrote: > On 05/08/12 00:32, Iain Buclaw wrote: >> On 7 May 2012 23:23, Artur Skawina <art.08.09@gmail.com> wrote: >>>> On 2012-05-07 21:53, Steven Schveighoffer wrote: >>>> >>>>> How do you overload the operator for a property? For example: >>> >>> It can of course be done [1], but i think the question was whether the >>> compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'. >>> Unconditionally, as not doing it every time would be confusing and lead >>> to bugs where the setter gets bypassed. >>> But what about the case where you want to return a ref to /different/ >>> objects? I guess mandating a setter wouldn't be problem, and still better >>> than the alternative. >>> >>> artur >>> >>> [1] I shouldn't even be posting this, as someone might actually think about using something like it... >>> >>> struct S { >>> int i; >>> @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; } >>> } >>> >>> int main() >>> { >>> S s; >>> s.p |= 2; >>> return s.p; >>> } >>> >>> struct PropProxy(RT, string sym) { >>> @property ref data() { return *cast(RT*)&this; } >>> @property ref get() { return __traits(getMember, data, sym); } >>> alias get this; >>> auto opOpAssign(string op, T)(T b) { >>> return mixin("data." ~ sym ~ " " ~ op ~ "= b"); >>> } >>> } >>> >>> Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just >>> out of curiosity, to check if GDC would be able to turn it all into >>> "mov $0x2, %eax; ret;". ;) >>> >> >> Your wishful thinking serves you well. :-) >> > > Just to make it clear - the above results in: > > 08049e50 <_Dmain>: > 8049e50: 55 push %ebp > 8049e51: b8 02 00 00 00 mov $0x2,%eax > 8049e56: 89 e5 mov %esp,%ebp > 8049e58: 5d pop %ebp > 8049e59: c3 ret > > and i believe that after Iain's recent GDC ABI changes the frame pointer manipulation is gone, so it all *really* compiles down to just one instruction. Frame pointer manipulation only now occurs on x86 for functions that compile in inline assembler (but not GCC inline assembler, and not naked functions). -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; |
May 08, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 2012-05-07 23:34, Jonathan M Davis wrote: > You mean the setter? Yes. > Having a getter property function return by ref does allow you to use a > property exactly as you would a variable, because you're operating on the ref > that's returned. It also makes the property function nigh-on-useless, because > then you're operating on its associated variable outside of the property > function, making it so that you can no longer control access to it. You pretty > much might as well make it a public variable at that point. Not to mention, > even if returning by ref didn't have that problem, it would only work in cases > where the property function was associated with an actual variable (since you > have to return a ref to _something_), so it would still be impossible to > emulate a variable with property functions which calculate the value from > other variables or which grab the value from somewhere else (e.g. a database). > > - Jonathan M Davis Exactly. -- /Jacob Carlborg |
May 14, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | I see. So where to vote for this enhancement? |
May 14, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael | On Monday, 14 May 2012 at 21:08:15 UTC, Michael wrote: > I see. > So where to vote for this enhancement? http://forum.dlang.org/thread/xcbweciovapinaicxgbn@forum.dlang.org?page=1#post-xcbweciovapinaicxgbn:40forum.dlang.org |
May 14, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael | On Monday, 14 May 2012 at 21:08:15 UTC, Michael wrote: > I see. > So where to vote for this enhancement? Ugh, wrong link... should've been: http://d.puremagic.com/issues/show_bug.cgi?id=8056 |
May 15, 2012 Re: Properties don't behave like variables? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On Monday, 14 May 2012 at 21:29:52 UTC, Mehrdad wrote:
> On Monday, 14 May 2012 at 21:08:15 UTC, Michael wrote:
>> I see.
>> So where to vote for this enhancement?
>
> Ugh, wrong link...
>
> should've been: http://d.puremagic.com/issues/show_bug.cgi?id=8056
Done.
|
Copyright © 1999-2021 by the D Language Foundation