View mode: basic / threaded / horizontal-split · Log in · Help
May 07, 2012
Re: Properties don't behave like variables?
> 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?
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?
I see.
So where to vote for this enhancement?
May 14, 2012
Re: Properties don't behave like variables?
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?
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?
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.
July 21, 2012
Re: Properties don't behave like variables?
Any news?
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home