www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On the subject of properties, and possibility of having them in the

reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Jan 26 2013
next sibling parent "mist" <none none.none> writes:
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
Jan 26 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Jan 26 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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;




        () => _n,
        value => _n = value
      ) n;
    }
 ...




http://d.puremagic.com/issues/show_bug.cgi?id=7653
Jan 26 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
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;




        () => _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.
Jan 27 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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;




        () => _n,
        value => _n = value
      ) n;
    }
 ...




 http://d.puremagic.com/issues/show_bug.cgi?id=7653



And how might that work?


-- 
Simen
Jan 26 2013
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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;




        () => _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
Jan 27 2013