www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ref returns and properties

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I realized that properties are not a complete model for actual data. The 
current conventional wisdom about properties goes like this (T is some 
type):

class Host
{
     property prop
     {
         T get() { ... }
         void set(T value) { ... }
     }
}

If T is e.g. an int, it all works nicely. Now consider T is a 
highly-structured piece of data that holds resources. In that case we 
want to make sure T is not copied unwittingly such that the resource is 
managed properly. This means that T has a copy constructor and a destructor.

For such cases, extensive experience with C++ has shown that two 
primitives are essential: move and swap.

void move(ref T src, ref T dst);
void swap(ref T lhs, ref T rhs);

Move takes the guts of src, puts them in dst, and then clears src 
effectively relieving it from any resource. Swap exchanges the guts of 
src and dst without any extra resource copying.

Now if "prop" were a classic data, swapping host1.prop and host2.prop is 
a piece of cake (that is realized inside std.algorithm. Look it up, the 
implementation has quite a few interesting quirks!)

But if "prop" is a property with get and set, everything falls apart. 
Properties effectively hide the address of the actual data and only 
traffic in values. That's often good (and sometimes even the only 
possibility in the case of properties computed on-the-fly), but this 
abstraction effectively makes resource-conserving move and swap impossible.

I noticed this problem when dealing with ranges. The .head() function, 
if it returns a value, cannot be swapped/moved. Same applies to opIndex 
when implemented as a value property (via the opIndex/opIndexAssign tandem).

What to do? I'd like to refine the notion of property such that moving 
properties around is possible, without, however, complicating their 
interface too much.


Andrei
Jan 25 2009
next sibling parent reply Michiel Helvensteijn <nomail please.com> writes:
Andrei Alexandrescu wrote:

 void move(ref T src, ref T dst);
 void swap(ref T lhs, ref T rhs);
 
 ...
 
 But if "prop" is a property with get and set, everything falls apart.
 Properties effectively hide the address of the actual data and only
 traffic in values. That's often good (and sometimes even the only
 possibility in the case of properties computed on-the-fly), but this
 abstraction effectively makes resource-conserving move and swap
 impossible.
 
 ...
 
 What to do? I'd like to refine the notion of property such that moving
 properties around is possible, without, however, complicating their
 interface too much.

I posted a possible solution to this (I think) in the last properties thread. I was thinking that properties might be equiped with extra member functions. One advantage is that you might get more efficiency. I think you just named another. class Host {      property prop      {          T get() { ... }          void set(T value) { ... } void move(ref T dst) { ... } void swap(ref T rhs) { ... }      } } Of course, in my idea (and my programming language), there is no difference between f(a, b) and a.f(b), so that automatically works out. Not sure how that would work out in D. One possibility is to just live with Host.prop.move(dst). -- Michiel
Jan 25 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:
 
 void move(ref T src, ref T dst);
 void swap(ref T lhs, ref T rhs);

 ...

 But if "prop" is a property with get and set, everything falls apart.
 Properties effectively hide the address of the actual data and only
 traffic in values. That's often good (and sometimes even the only
 possibility in the case of properties computed on-the-fly), but this
 abstraction effectively makes resource-conserving move and swap
 impossible.

 ...

 What to do? I'd like to refine the notion of property such that moving
 properties around is possible, without, however, complicating their
 interface too much.

I posted a possible solution to this (I think) in the last properties thread. I was thinking that properties might be equiped with extra member functions. One advantage is that you might get more efficiency. I think you just named another. class Host { property prop { T get() { ... } void set(T value) { ... } void move(ref T dst) { ... } void swap(ref T rhs) { ... } } }

But these are too many. These should suffice: class Host { property prop { T get(); void acquire(ref T value) { ... } void release(ref T value) { ... } } } set() can be implemented as acquire from a copy, and swap can be implemented by calls to acquire and release. Technically, get() could be also implemented with acquire and release, but that's too intensive for most types. The problem I'm seeing is that most people won't want to go through the trouble of implementing three functions for one property. Andrei
Jan 25 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sun, Jan 25, 2009 at 3:00 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 But these are too many. These should suffice:

 class Host
 {
     property prop
     {
         T get();
         void acquire(ref T value) { ... }
         void release(ref T value) { ... }
     }
 }

 set() can be implemented as acquire from a copy, and swap can be implemented
 by calls to acquire and release. Technically, get() could be also
 implemented with acquire and release, but that's too intensive for most
 types.

 The problem I'm seeing is that most people won't want to go through the
 trouble of implementing three functions for one property.

I absolutely wouldn't. Once we start doing stuff like that, we start getting into tedious C++ territory. Holding the compiler's hand, writing mountains of tedious, easy-to-mess-up boilerplate code, just to be able to implement simple things so they fit in with the language's weird semantics. At that point I'd _rather_ use the current "properties."

But you lose correctness and efficiency. I agree that in certain cases they aren't paramount, but you can't build a language to not allow them. A possible solution would be to require only get, make acquire necessary only for writable properties, and make release entirely optional. Andrei
Jan 25 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Mon, 26 Jan 2009 00:59:32 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Jarrett Billingsley wrote:
 On Sun, Jan 25, 2009 at 3:00 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 But these are too many. These should suffice:

 class Host
 {
     property prop
     {
         T get();
         void acquire(ref T value) { ... }
         void release(ref T value) { ... }
     }
 }

 set() can be implemented as acquire from a copy, and swap can be 
 implemented
 by calls to acquire and release. Technically, get() could be also
 implemented with acquire and release, but that's too intensive for most
 types.

 The problem I'm seeing is that most people won't want to go through the
 trouble of implementing three functions for one property.

getting into tedious C++ territory. Holding the compiler's hand, writing mountains of tedious, easy-to-mess-up boilerplate code, just to be able to implement simple things so they fit in with the language's weird semantics. At that point I'd _rather_ use the current "properties."

But you lose correctness and efficiency. I agree that in certain cases they aren't paramount, but you can't build a language to not allow them. A possible solution would be to require only get, make acquire necessary only for writable properties, and make release entirely optional. Andrei

get/set/free?

With these you can't move a resource inside the property. Andrei
Jan 25 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 [snip]

 get/set/free?

With these you can't move a resource inside the property. Andrei

Python has an overload for removing properties. In all my years of using Python, I've *NEVER* once had a use for it, or even worked out why I'd want to use it. I'm not saying we shouldn't be able to do this, I just can't see the need for move/remove for properties; where would this be useful? -- Daniel
Jan 25 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 [snip]

 get/set/free?

Andrei

Python has an overload for removing properties. In all my years of using Python, I've *NEVER* once had a use for it, or even worked out why I'd want to use it. I'm not saying we shouldn't be able to do this, I just can't see the need for move/remove for properties; where would this be useful?

Does Python have complex value types? Sean
Jan 26 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Sean Kelly wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 [snip]

 get/set/free?

Andrei

Python has an overload for removing properties. In all my years of using Python, I've *NEVER* once had a use for it, or even worked out why I'd want to use it. I'm not saying we shouldn't be able to do this, I just can't see the need for move/remove for properties; where would this be useful?

Does Python have complex value types? Sean

You mean these?
 (1+2j) * (2+3j)



Don't ask me why they used 'j' instead of 'i'. :P If you mean aggregate types that have value semantics, then no. -- Daniel
Jan 26 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 
 Sean Kelly wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 [snip]

 get/set/free?

Andrei

using Python, I've *NEVER* once had a use for it, or even worked out why I'd want to use it. I'm not saying we shouldn't be able to do this, I just can't see the need for move/remove for properties; where would this be useful?

Sean

You mean these?
 (1+2j) * (2+3j)



Don't ask me why they used 'j' instead of 'i'. :P If you mean aggregate types that have value semantics, then no.

He meant the latter (emphasis on the other syllable, I always forget which is which). This brings back the notion of precision and efficiency. C++ tries to define operations such that some never throw, as those can be used in code with transactional semantics. It also tries to manage resources deterministically, which means there's strict control over values being created and destroyed. It's hard to combine these two within a harmonious system. Anyhow, here's a simple D example. Consider we define a BigInt type as a value-type struct: when you copy a BigInt to another, the latter becomes an independent copy: BigInt a = 100; BigInt b = a; ++b; assert(a == 100); BigInt's copy constructor would allocate memory dynamically, which means it may throw and also that it is inefficient to copy BigInt objects unwittingly. So far, so good. Now say we define some range that iterates over BigInts. If that range chooses to implement head() as a property, then a copy is created whenever you ask for head. The small problem is that that's inefficient. The larger problem is that there is no way to correctly e.g. sort such a range. Sorting hinges on swap, and with properties you can't ever swap without risking to throw. Sort would end up throwing, and not only throwing, but losing state irretrievably while at it. Well that's not a foundation we want to build D on, do we? Andrei
Jan 26 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 26 Jan 2009 08:06:05 -0800, Andrei Alexandrescu wrote:

 Anyhow, here's a simple D example. Consider we define a BigInt type as a 
 value-type struct: when you copy a BigInt to another, the latter becomes 
 an independent copy:
 
 BigInt a = 100;
 BigInt b = a;
 ++b;
 assert(a == 100);
 
 BigInt's copy constructor would allocate memory dynamically, which means 
 it may throw and also that it is inefficient to copy BigInt objects 
 unwittingly.
 
 So far, so good. Now say we define some range that iterates over 
 BigInts. If that range chooses to implement head() as a property, then a 
 copy is created whenever you ask for head. The small problem is that 
 that's inefficient. The larger problem is that there is no way to 
 correctly e.g. sort such a range. Sorting hinges on swap, and with 
 properties you can't ever swap without risking to throw. Sort would end 
 up throwing, and not only throwing, but losing state irretrievably while 
 at it. Well that's not a foundation we want to build D on, do we?

This will happen in C++, too, if operator*() decides to throw. Algorithms are correct only if objects they manipulate obey the rules. It seems like your rule is, 'forward ranges are nothrow.' Any senior ranges included. Or maybe throwing next() or empty() are less dangerous?
Jan 26 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Mon, 26 Jan 2009 08:06:05 -0800, Andrei Alexandrescu wrote:
 
 Anyhow, here's a simple D example. Consider we define a BigInt type as a 
 value-type struct: when you copy a BigInt to another, the latter becomes 
 an independent copy:

 BigInt a = 100;
 BigInt b = a;
 ++b;
 assert(a == 100);

 BigInt's copy constructor would allocate memory dynamically, which means 
 it may throw and also that it is inefficient to copy BigInt objects 
 unwittingly.

 So far, so good. Now say we define some range that iterates over 
 BigInts. If that range chooses to implement head() as a property, then a 
 copy is created whenever you ask for head. The small problem is that 
 that's inefficient. The larger problem is that there is no way to 
 correctly e.g. sort such a range. Sorting hinges on swap, and with 
 properties you can't ever swap without risking to throw. Sort would end 
 up throwing, and not only throwing, but losing state irretrievably while 
 at it. Well that's not a foundation we want to build D on, do we?

This will happen in C++, too, if operator*() decides to throw. Algorithms are correct only if objects they manipulate obey the rules.

Of course. The problem with get and set is not that they make it possible to write incorrect code. They make it impossible to write correct code.
 It seems like your rule is, 'forward ranges are nothrow.'  Any senior
 ranges included.  Or maybe throwing next() or empty() are less
 dangerous?

Yes, because even if they throw, net loss of state is still avoidable. Andrei
Jan 26 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 Sean Kelly wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 [snip]

 get/set/free?

Andrei

Python has an overload for removing properties. In all my years of using Python, I've *NEVER* once had a use for it, or even worked out why I'd want to use it. I'm not saying we shouldn't be able to do this, I just can't see the need for move/remove for properties; where would this be useful?

Does Python have complex value types? Sean

 (1+2j) * (2+3j)



Don't ask me why they used 'j' instead of 'i'. :P If you mean aggregate types that have value semantics, then no. -- Daniel

Using j instead of i is pretty common in electrical engineering circles. i means current when dealing with circuits, and complex numbers are used all over the place to make the math easier when doing circuit stuff, so by convention j is used instead of i to denote imaginary numbers.
Jan 26 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello dsimcha,

 == Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 
 Sean Kelly wrote:
 
 Daniel Keep wrote:
 
 Andrei Alexandrescu wrote:
 
 Denis Koroskin wrote:
 
 [snip]
 
 get/set/free?
 

Andrei

using Python, I've *NEVER* once had a use for it, or even worked out why I'd want to use it. I'm not saying we shouldn't be able to do this, I just can't see the need for move/remove for properties; where would this be useful?

Sean

 (1+2j) * (2+3j)
 



Don't ask me why they used 'j' instead of 'i'. :P If you mean aggregate types that have value semantics, then no. -- Daniel

circles. i means current when dealing with circuits, and complex numbers are used all over the place to make the math easier when doing circuit stuff, so by convention j is used instead of i to denote imaginary numbers.

Right, the 'j' notation is used in the representation of phasors in ac circuit analysis. If I remember correctly, 'i' , usually represented as a function of time, is the changing current (like in a sinusoidal waveform)... and 'I' is the instantaneous current. I used to do a lot of phasor calculation practice. :-P -JJR
Jan 26 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sun, Jan 25, 2009 at 4:59 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 But you lose correctness and efficiency. I agree that in certain cases they
 aren't paramount, but you can't build a language to not allow them.

Correctness is fine, but efficiency be damned.

You and I don't seem to frequent the same circles.
 Look at where _that_
 mantra has gotten C++.

Not sure that efficiency is the source of most or even many of the known issues with C++. Andrei
Jan 25 2009
prev sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Andrei Alexandrescu wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 void move(ref T src, ref T dst);
 void swap(ref T lhs, ref T rhs);

 ...

 But if "prop" is a property with get and set, everything falls apart.
 Properties effectively hide the address of the actual data and only
 traffic in values. That's often good (and sometimes even the only
 possibility in the case of properties computed on-the-fly), but this
 abstraction effectively makes resource-conserving move and swap
 impossible.

 ...

 What to do? I'd like to refine the notion of property such that moving
 properties around is possible, without, however, complicating their
 interface too much.

I posted a possible solution to this (I think) in the last properties thread. I was thinking that properties might be equiped with extra member functions. One advantage is that you might get more efficiency. I think you just named another. class Host { property prop { T get() { ... } void set(T value) { ... } void move(ref T dst) { ... } void swap(ref T rhs) { ... } } }

But these are too many. These should suffice: class Host { property prop { T get(); void acquire(ref T value) { ... } void release(ref T value) { ... } } } set() can be implemented as acquire from a copy, and swap can be implemented by calls to acquire and release. Technically, get() could be also implemented with acquire and release, but that's too intensive for most types. The problem I'm seeing is that most people won't want to go through the trouble of implementing three functions for one property. Andrei

What about this: class Host { property acquire release prop { T get(); } } And then the compiler will automatically created the "acquire" and "release" methods. There could also be what I would like to call "property shortcuts" (ruby calls this attributes) like this: class Host { get acquire release T prop; get set T prop2; }
Jan 26 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jacob Carlborg wrote:
[on properties]
 What about this:
 
 class Host
 {
      property acquire release prop
      {
          T get();
      }
 }
 
 And then the compiler will automatically created the "acquire" and 
 "release" methods.
 
 There could also be what I would like to call "property shortcuts" (ruby 
 calls this attributes) like this:
 
 class Host
 {
      get acquire release T prop;
      get set T prop2;
 }

I was hoping I'd shield putative users from having to write verbose code. Besides, there's one other issue I stumbled upon while working on porting std.algorithm to ranges. You can't really pass an entire property to a function. This furthers the rift between properties and true fields. Consider: struct A { int x; } void foo(ref int n) { if (n == 0) n = 1; } ... A obj; foo(obj.x); So when passing obj.x to foo, foo can read and write it no problem. But if x is a property of A, it all falls apart: obj.x means just reading the property, not getting the property with all of its get and set splendor. How did this hit me in std.algorithm? Replace A with your range of choice, x with head, and foo with swap. If head is implemented as a property instead of a ref-returning function or a field, I can't swap the heads of two ranges!! This limits how ranges can be implemented; I was hoping to allow head as a property, but it looks like I can't. Same goes about opIndex. If you define a random-access range, you can't define opIndex and opIndexAssign. You must define opIndex to return a reference. That's a bummer. Andrei
Jan 26 2009
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Jacob Carlborg wrote:
 [on properties]
 What about this:

 class Host
 {
      property acquire release prop
      {
          T get();
      }
 }

 And then the compiler will automatically created the "acquire" and 
 "release" methods.

 There could also be what I would like to call "property shortcuts" 
 (ruby calls this attributes) like this:

 class Host
 {
      get acquire release T prop;
      get set T prop2;
 }

I was hoping I'd shield putative users from having to write verbose code. Besides, there's one other issue I stumbled upon while working on porting std.algorithm to ranges. You can't really pass an entire property to a function. This furthers the rift between properties and true fields. Consider: struct A { int x; } void foo(ref int n) { if (n == 0) n = 1; } ... A obj; foo(obj.x); So when passing obj.x to foo, foo can read and write it no problem. But if x is a property of A, it all falls apart: obj.x means just reading the property, not getting the property with all of its get and set splendor.

I'm starting to wonder if we need some restrictions on fields, in order to make properties and fields interchangable. The idea that a field could eventually be completely replaceable with functions is appealing, but I think it's only possible with a huge performance hit. One can distinguish between POD fields (for which any operation is legal) and property fields (which you cannot take the address of, for example). Arguably classes should normally not contain public POD fields, only public property fields. Perhaps this is a useful concept. Incidentally, a simpler way of bridging the divide would have been to drop property syntax and instead allow public fields to be accessed using function notation. Setting would be similar to C++ constructors: int z = obj.x() + 7; obj.x(6);
 How did this hit me in std.algorithm? Replace A with your range of 
 choice, x with head, and foo with swap. If head is implemented as a 
 property instead of a ref-returning function or a field, I can't swap 
 the heads of two ranges!! This limits how ranges can be implemented; I 
 was hoping to allow head as a property, but it looks like I can't. Same 
 goes about opIndex. If you define a random-access range, you can't 
 define opIndex and opIndexAssign. You must define opIndex to return a 
 reference. That's a bummer.

Yuck.
 
 
 Andrei

Jan 26 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Jacob Carlborg wrote:
 [on properties]
 What about this:

 class Host
 {
      property acquire release prop
      {
          T get();
      }
 }

 And then the compiler will automatically created the "acquire" and 
 "release" methods.

 There could also be what I would like to call "property shortcuts" 
 (ruby calls this attributes) like this:

 class Host
 {
      get acquire release T prop;
      get set T prop2;
 }

I was hoping I'd shield putative users from having to write verbose code. Besides, there's one other issue I stumbled upon while working on porting std.algorithm to ranges. You can't really pass an entire property to a function. This furthers the rift between properties and true fields. Consider: struct A { int x; } void foo(ref int n) { if (n == 0) n = 1; } ... A obj; foo(obj.x); So when passing obj.x to foo, foo can read and write it no problem. But if x is a property of A, it all falls apart: obj.x means just reading the property, not getting the property with all of its get and set splendor.

I'm starting to wonder if we need some restrictions on fields, in order to make properties and fields interchangable. The idea that a field could eventually be completely replaceable with functions is appealing, but I think it's only possible with a huge performance hit. One can distinguish between POD fields (for which any operation is legal) and property fields (which you cannot take the address of, for example). Arguably classes should normally not contain public POD fields, only public property fields. Perhaps this is a useful concept.

I'm hesitant to assert that it should be illegal to take the address of a public data member, but this is certainly an intriguing idea. The only other option I can think of would be to make swap a built-in property of concrete types and expecting the user to call a.swap(b), though it seems weird that a.swap(b) couldn't be rewritten as swap(a,b) for any concrete type, regardless of context. Sean
Jan 26 2009
parent Don <nospam nospam.com> writes:
Sean Kelly wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 Jacob Carlborg wrote:
 [on properties]
 What about this:

 class Host
 {
      property acquire release prop
      {
          T get();
      }
 }

 And then the compiler will automatically created the "acquire" and 
 "release" methods.

 There could also be what I would like to call "property shortcuts" 
 (ruby calls this attributes) like this:

 class Host
 {
      get acquire release T prop;
      get set T prop2;
 }

I was hoping I'd shield putative users from having to write verbose code. Besides, there's one other issue I stumbled upon while working on porting std.algorithm to ranges. You can't really pass an entire property to a function. This furthers the rift between properties and true fields. Consider: struct A { int x; } void foo(ref int n) { if (n == 0) n = 1; } ... A obj; foo(obj.x); So when passing obj.x to foo, foo can read and write it no problem. But if x is a property of A, it all falls apart: obj.x means just reading the property, not getting the property with all of its get and set splendor.

I'm starting to wonder if we need some restrictions on fields, in order to make properties and fields interchangable. The idea that a field could eventually be completely replaceable with functions is appealing, but I think it's only possible with a huge performance hit. One can distinguish between POD fields (for which any operation is legal) and property fields (which you cannot take the address of, for example). Arguably classes should normally not contain public POD fields, only public property fields. Perhaps this is a useful concept.

I'm hesitant to assert that it should be illegal to take the address of a public data member, but this is certainly an intriguing idea.

At least, it's something you could do in a lint tool. I think it would be a useful warning for classes. It still wouldn't solve Andrei's problem, though, because you still need public fields of structs to be POD fields, and a struct can still have properties. Then there are module properties... The
 only other option I can think of would be to make swap a built-in 
 property of concrete types and expecting the user to call a.swap(b), 
 though it seems weird that a.swap(b) couldn't be rewritten as swap(a,b) 
 for any concrete type, regardless of context.

 
 
 Sean

Jan 27 2009
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Jacob Carlborg wrote:
 Andrei Alexandrescu wrote:
 Michiel Helvensteijn wrote:
 Andrei Alexandrescu wrote:

 void move(ref T src, ref T dst);
 void swap(ref T lhs, ref T rhs);

 ...

 But if "prop" is a property with get and set, everything falls apart.
 Properties effectively hide the address of the actual data and only
 traffic in values. That's often good (and sometimes even the only
 possibility in the case of properties computed on-the-fly), but this
 abstraction effectively makes resource-conserving move and swap
 impossible.

 ...

 What to do? I'd like to refine the notion of property such that moving
 properties around is possible, without, however, complicating their
 interface too much.

I posted a possible solution to this (I think) in the last properties thread. I was thinking that properties might be equiped with extra member functions. One advantage is that you might get more efficiency. I think you just named another. class Host { property prop { T get() { ... } void set(T value) { ... } void move(ref T dst) { ... } void swap(ref T rhs) { ... } } }

But these are too many. These should suffice: class Host { property prop { T get(); void acquire(ref T value) { ... } void release(ref T value) { ... } } } set() can be implemented as acquire from a copy, and swap can be implemented by calls to acquire and release. Technically, get() could be also implemented with acquire and release, but that's too intensive for most types. The problem I'm seeing is that most people won't want to go through the trouble of implementing three functions for one property. Andrei

What about this: class Host { property acquire release prop { T get(); } } And then the compiler will automatically created the "acquire" and "release" methods. There could also be what I would like to call "property shortcuts" (ruby calls this attributes) like this: class Host { get acquire release T prop; get set T prop2; }

I agree with Daniel and I think that 99.999% of users will use properties with just get/set methods and those should be the methods for defining properties, _not_ acquire/release as above. the other 0.001% can just define extra functions in the body of the property. The design should be geared towards the common and simple case.
Jan 26 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Jan 25, 2009 at 3:00 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 But these are too many. These should suffice:

 class Host
 {
     property prop
     {
         T get();
         void acquire(ref T value) { ... }
         void release(ref T value) { ... }
     }
 }

 set() can be implemented as acquire from a copy, and swap can be implemented
 by calls to acquire and release. Technically, get() could be also
 implemented with acquire and release, but that's too intensive for most
 types.

 The problem I'm seeing is that most people won't want to go through the
 trouble of implementing three functions for one property.

I absolutely wouldn't. Once we start doing stuff like that, we start getting into tedious C++ territory. Holding the compiler's hand, writing mountains of tedious, easy-to-mess-up boilerplate code, just to be able to implement simple things so they fit in with the language's weird semantics. At that point I'd _rather_ use the current "properties."
Jan 25 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 26 Jan 2009 00:59:32 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Jarrett Billingsley wrote:
 On Sun, Jan 25, 2009 at 3:00 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 But these are too many. These should suffice:

 class Host
 {
     property prop
     {
         T get();
         void acquire(ref T value) { ... }
         void release(ref T value) { ... }
     }
 }

 set() can be implemented as acquire from a copy, and swap can be  
 implemented
 by calls to acquire and release. Technically, get() could be also
 implemented with acquire and release, but that's too intensive for most
 types.

 The problem I'm seeing is that most people won't want to go through the
 trouble of implementing three functions for one property.

getting into tedious C++ territory. Holding the compiler's hand, writing mountains of tedious, easy-to-mess-up boilerplate code, just to be able to implement simple things so they fit in with the language's weird semantics. At that point I'd _rather_ use the current "properties."

But you lose correctness and efficiency. I agree that in certain cases they aren't paramount, but you can't build a language to not allow them. A possible solution would be to require only get, make acquire necessary only for writable properties, and make release entirely optional. Andrei

get/set/free?
Jan 25 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Jan 25, 2009 at 4:59 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 But you lose correctness and efficiency. I agree that in certain cases they
 aren't paramount, but you can't build a language to not allow them.

Correctness is fine, but efficiency be damned. Look at where _that_ mantra has gotten C++.
Jan 25 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
I realized that properties are not a complete model for actual data. The 
current conventional wisdom about properties goes like this (T is some 
type):

 class Host
 {
     property prop
     {
         T get() { ... }
         void set(T value) { ... }
     }
 }

 If T is e.g. an int, it all works nicely. Now consider T is a 
 highly-structured piece of data that holds resources. In that case we want 
 to make sure T is not copied unwittingly such that the resource is managed 
 properly. This means that T has a copy constructor and a destructor.

 For such cases, extensive experience with C++ has shown that two 
 primitives are essential: move and swap.

 void move(ref T src, ref T dst);
 void swap(ref T lhs, ref T rhs);

 Move takes the guts of src, puts them in dst, and then clears src 
 effectively relieving it from any resource. Swap exchanges the guts of src 
 and dst without any extra resource copying.

 Now if "prop" were a classic data, swapping host1.prop and host2.prop is a 
 piece of cake (that is realized inside std.algorithm. Look it up, the 
 implementation has quite a few interesting quirks!)

 But if "prop" is a property with get and set, everything falls apart. 
 Properties effectively hide the address of the actual data and only 
 traffic in values. That's often good (and sometimes even the only 
 possibility in the case of properties computed on-the-fly), but this 
 abstraction effectively makes resource-conserving move and swap 
 impossible.

 I noticed this problem when dealing with ranges. The .head() function, if 
 it returns a value, cannot be swapped/moved. Same applies to opIndex when 
 implemented as a value property (via the opIndex/opIndexAssign tandem).

 What to do? I'd like to refine the notion of property such that moving 
 properties around is possible, without, however, complicating their 
 interface too much.

There are two possibilities that I can think of. 1. ref return from get, which gets you part-way there. You can still do some useful things like which member you are returning getting calculated, but it doesn't make the call to set when you assign to the property, or allow calling get multiple times to return different values. 2. Have a "property delegate", which is like a normal delegate, but contains 2 functions. Calling a function which takes such a delegate makes the compiler generate such a delegate in the case where a simple lvalue is passed. You could signify it with the terms "lazy ref" in the function signature. option 1 is the simple solution, and covers some ground. I don't think it's universally useful, but it could provide a mechanism for things like head() to work. option 2 solves the problem, but introduces some complex, possibly performance hurting mechanisms. The way to solve this last part is probably to allow specification of multiple functions, and have the compiler choose the non 'lazy-ref' version if it is passed a simple lvalue. example usage of #2: class C { private int _x; private int _y; this(int n) { _x = n; } property prop { int get() { return _y; } void set(int x) { _y += _x * x; } // some weird semantics for set } } void foo(lazy ref z) { z += 100; } translates to: struct property_delegate(T) { void *ptr; T function(void*) get; void function(void *, T) set; } void foo(property_delegate!(int) pd) { pd.set(pd.ptr, pd.get(pd.ptr) + 100); } usage: void bar() { auto c = new C(2); /* generates a property delegate with prop.get and prop.set as the functions, and c as the pointer */ foo(c.prop); assert(c.prop == 200); int n = c.prop; /* generates a property delegate with get and set functions being generated inner functions of bar which set and get n, and the stack frame as the pointer. */ foo(n); assert(n == 300); } -Steve
Jan 26 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 "Andrei Alexandrescu" wrote
 I realized that properties are not a complete model for actual data. The 
 current conventional wisdom about properties goes like this (T is some 
 type):

 class Host
 {
     property prop
     {
         T get() { ... }
         void set(T value) { ... }
     }
 }

 If T is e.g. an int, it all works nicely. Now consider T is a 
 highly-structured piece of data that holds resources. In that case we want 
 to make sure T is not copied unwittingly such that the resource is managed 
 properly. This means that T has a copy constructor and a destructor.

 For such cases, extensive experience with C++ has shown that two 
 primitives are essential: move and swap.

 void move(ref T src, ref T dst);
 void swap(ref T lhs, ref T rhs);

 Move takes the guts of src, puts them in dst, and then clears src 
 effectively relieving it from any resource. Swap exchanges the guts of src 
 and dst without any extra resource copying.

 Now if "prop" were a classic data, swapping host1.prop and host2.prop is a 
 piece of cake (that is realized inside std.algorithm. Look it up, the 
 implementation has quite a few interesting quirks!)

 But if "prop" is a property with get and set, everything falls apart. 
 Properties effectively hide the address of the actual data and only 
 traffic in values. That's often good (and sometimes even the only 
 possibility in the case of properties computed on-the-fly), but this 
 abstraction effectively makes resource-conserving move and swap 
 impossible.

 I noticed this problem when dealing with ranges. The .head() function, if 
 it returns a value, cannot be swapped/moved. Same applies to opIndex when 
 implemented as a value property (via the opIndex/opIndexAssign tandem).

 What to do? I'd like to refine the notion of property such that moving 
 properties around is possible, without, however, complicating their 
 interface too much.

There are two possibilities that I can think of. 1. ref return from get, which gets you part-way there. You can still do some useful things like which member you are returning getting calculated, but it doesn't make the call to set when you assign to the property, or allow calling get multiple times to return different values.

Yah, exactly. One thing I'm rather sad about is that certain containers won't be implementable that way, for example sparse vectors (with most elements zero). A sparse vector would want to return by value from head() and opIndex() (so it can return 0.0 most of the time) and would also want to have control over setting slots. So in brief, sparse vectors won't be supported naturally by our paradigm. They will still be supported, just not in a manner that makes them next to indistinguishable from dense vectors. Lately I'm getting to think (sour grapes syndrome?) that probably that's a good thing. A sparse vector is very long - e.g. millions of items, and only has a few or a few hundred that are nonzero. It would be wasteful to ever iterate over the whole one million items; I'd rather use a custom algorithm that only "sees" the nonzero elements. It would be nice to have opApply work, but I guess I can live with that too.
 2. Have a "property delegate", which is like a normal delegate, but contains 
 2 functions.  Calling a function which takes such a delegate makes the 
 compiler generate such a delegate in the case where a simple lvalue is 
 passed.  You could signify it with the terms "lazy ref" in the function 
 signature.

Yah, crossed my mind too. With the third function in tow (the one that does the resource acquisition or whatnot) things are getting rather overweight and it starts looking like a full-fledged local class with a vtable and the works might be an option. Local classes have access to the frame pointer of their parent, so probably things can be arranged to work. But the cost of the whole operation becomes too high. Andrei
Jan 26 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 There are two possibilities that I can think of.

 1. ref return from get, which gets you part-way there.  You can still do 
 some useful things like which member you are returning getting 
 calculated, but it doesn't make the call to set when you assign to the 
 property, or allow calling get multiple times to return different values.

Yah, exactly. One thing I'm rather sad about is that certain containers won't be implementable that way, for example sparse vectors (with most elements zero). A sparse vector would want to return by value from head() and opIndex() (so it can return 0.0 most of the time) and would also want to have control over setting slots. So in brief, sparse vectors won't be supported naturally by our paradigm. They will still be supported, just not in a manner that makes them next to indistinguishable from dense vectors. Lately I'm getting to think (sour grapes syndrome?) that probably that's a good thing. A sparse vector is very long - e.g. millions of items, and only has a few or a few hundred that are nonzero. It would be wasteful to ever iterate over the whole one million items; I'd rather use a custom algorithm that only "sees" the nonzero elements. It would be nice to have opApply work, but I guess I can live with that too.

A good point. Let's not forget that the main purpose of ranges being special is to support foreach. Once you start using ranges in different ways, then it becomes more of a generalized structure, up to the library designer as to how to solve these problems.
 2. Have a "property delegate", which is like a normal delegate, but 
 contains 2 functions.  Calling a function which takes such a delegate 
 makes the compiler generate such a delegate in the case where a simple 
 lvalue is passed.  You could signify it with the terms "lazy ref" in the 
 function signature.

Yah, crossed my mind too. With the third function in tow (the one that does the resource acquisition or whatnot) things are getting rather overweight and it starts looking like a full-fledged local class with a vtable and the works might be an option. Local classes have access to the frame pointer of their parent, so probably things can be arranged to work. But the cost of the whole operation becomes too high.

I guess I'm not really sure what the "acquire" method does. I saw you mention it in another post, but with no explanation as to what it actually does, just that it was needed. I'm sure I'm not getting what should be obvious, but if you could enlighten, I would appreciate it :) Having the two functions seems like a reasonable baggage compromise, if you want to control the get and set methods of a property and pass that control to an underlying function, you need at least that. If we start generalizing it to anything, then it starts looking like struct interfaces would be more suitable. For example, you could allow setting an int property using both an int and a string, do you want to pass both setters to a function? I think limiting it to just a set and a get function should be sufficient. -Steve
Jan 26 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 I guess I'm not really sure what the "acquire" method does.  I saw you 
 mention it in another post, but with no explanation as to what it actually 
 does, just that it was needed.  I'm sure I'm not getting what should be 
 obvious, but if you could enlighten, I would appreciate it :)

Say you have an object obj that has a Matrix property and you have a Matrix object handy. The Matrix is rather resource intensive so you'd rather not copy it unwittingly. Conventionally, if you say: Matrix m; ... fill matrix ... obj.matrix = m; then m is copied into obj.matrix (there is the by-value call to set property). Now it's possible to arrange things such that m is destructively copied, but as the auto_ptr disaster has shown, it's not that intuitive to make assignment destroy the right hand side. So we'd need a distinct method: obj.matrix.acquire(m); That method takes the matrix by reference, sucks its life out of it, and leaves an empty shell behind. Pretty much like in your average horror movie.
 Having the two functions seems like a reasonable baggage compromise, if you 
 want to control the get and set methods of a property and pass that control 
 to an underlying function, you need at least that.  If we start generalizing 
 it to anything, then it starts looking like struct interfaces would be more 
 suitable.  For example, you could allow setting an int property using both 
 an int and a string, do you want to pass both setters to a function?  I 
 think limiting it to just a set and a get function should be sufficient.

With only get and set I can't implement a nothrow swap, which kinda bends me out of shape. Andrei
Jan 26 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 I guess I'm not really sure what the "acquire" method does.  I saw you 
 mention it in another post, but with no explanation as to what it 
 actually does, just that it was needed.  I'm sure I'm not getting what 
 should be obvious, but if you could enlighten, I would appreciate it :)

Say you have an object obj that has a Matrix property and you have a Matrix object handy. The Matrix is rather resource intensive so you'd rather not copy it unwittingly. Conventionally, if you say: Matrix m; ... fill matrix ... obj.matrix = m; then m is copied into obj.matrix (there is the by-value call to set property). Now it's possible to arrange things such that m is destructively copied, but as the auto_ptr disaster has shown, it's not that intuitive to make assignment destroy the right hand side. So we'd need a distinct method: obj.matrix.acquire(m); That method takes the matrix by reference, sucks its life out of it, and leaves an empty shell behind. Pretty much like in your average horror movie.

So what you are saying is that you want to control the set such that it destroys the source (essentially, I'm reading, you don't want to do a deep copy, just a reference copy, and then null the original reference). Let me ask another question then... does a property have reason to have both set AND acquire? More specifically, does a function that takes a property as an argument as we have been discussing need both set and acquire passed to it? If not, you can simply pass the set method that you want, still only requiring a pair of functions. How to signal that to the compiler easily? Not so sure... but it does seem to me like a type should know how it should be copied, and likely doing it other ways should require special methods. I can think of possible library solutions to this, say a wrapper property struct that can call any two functions to do set or get.
 Having the two functions seems like a reasonable baggage compromise, if 
 you want to control the get and set methods of a property and pass that 
 control to an underlying function, you need at least that.  If we start 
 generalizing it to anything, then it starts looking like struct 
 interfaces would be more suitable.  For example, you could allow setting 
 an int property using both an int and a string, do you want to pass both 
 setters to a function?  I think limiting it to just a set and a get 
 function should be sufficient.

With only get and set I can't implement a nothrow swap, which kinda bends me out of shape.

Sorry, don't get that either. Why can't set and get be used in a nothrow swap? -Steve
Jan 26 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Denis Koroskin" wrote
 On Tue, 27 Jan 2009 01:52:26 +0300, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 I guess I'm not really sure what the "acquire" method does.  I saw you
 mention it in another post, but with no explanation as to what it
 actually does, just that it was needed.  I'm sure I'm not getting what
 should be obvious, but if you could enlighten, I would appreciate it :)

Say you have an object obj that has a Matrix property and you have a Matrix object handy. The Matrix is rather resource intensive so you'd rather not copy it unwittingly. Conventionally, if you say: Matrix m; ... fill matrix ... obj.matrix = m; then m is copied into obj.matrix (there is the by-value call to set property). Now it's possible to arrange things such that m is destructively copied, but as the auto_ptr disaster has shown, it's not that intuitive to make assignment destroy the right hand side. So we'd need a distinct method: obj.matrix.acquire(m); That method takes the matrix by reference, sucks its life out of it, and leaves an empty shell behind. Pretty much like in your average horror movie.

So what you are saying is that you want to control the set such that it destroys the source (essentially, I'm reading, you don't want to do a deep copy, just a reference copy, and then null the original reference). Let me ask another question then... does a property have reason to have both set AND acquire? More specifically, does a function that takes a property as an argument as we have been discussing need both set and acquire passed to it? If not, you can simply pass the set method that you want, still only requiring a pair of functions. How to signal that to the compiler easily? Not so sure... but it does seem to me like a type should know how it should be copied, and likely doing it other ways should require special methods. I can think of possible library solutions to this, say a wrapper property struct that can call any two functions to do set or get.
 Having the two functions seems like a reasonable baggage compromise, if
 you want to control the get and set methods of a property and pass that
 control to an underlying function, you need at least that.  If we start
 generalizing it to anything, then it starts looking like struct
 interfaces would be more suitable.  For example, you could allow 
 setting
 an int property using both an int and a string, do you want to pass 
 both
 setters to a function?  I think limiting it to just a set and a get
 function should be sufficient.

With only get and set I can't implement a nothrow swap, which kinda bends me out of shape.

Sorry, don't get that either. Why can't set and get be used in a nothrow swap? -Steve

Because set implies data copying (read: allocation) and copy constructor call, both of which can throw. How about the following - you call a swap with a dot syntax: int x = 42; int y = 13; x.swap(y); // calls global void swap(T)(ref T, ref T); or a specialized version, swap(ref int, ref int); User is, however, free to implement his own swap method: struct BigInt { ... void swap(ref BigInt other) { ... } ... } Or another way - "void swap(T)(ref T lhs, ref T rhs);" tries "lhs.swap(rhs);" first, and falls back to "auto tmp = lhs; lhs = rhs; rhs = tmp;" if no lhs.swap method is defined. This way you can define "void aquire(ref T newOwner, ref T data);" as "newOwner.aquire(data);" and fall back to "swap(newOwner, data); release(data);" on failure. "void release(ref T obj);" tries "obj.release();" first and falls back to "swap(obj, T());" or "obj = T();" on failure.

OK, I think I got what you and Andrei are saying. I had to think about this a while, and I think Denis is right. Leave the swap implementation up to the type, not the holder of the type. A property should be a simple interface to define how to access an object's data, which is the most common case. Putting in all these extra methods and features to allow the possibility of a non-specific swap function for certain uncommon cases seems like you are trying to remove complexity from an opaque low level function and adding the complexity to all properties in existance instead. i.e. if you want to sort an array of matrices which are expensive to make copies of, then you need a special swap, you can't use the generic one, because it's not a generic swap. Let the type tell you how to do it or let the developer pass in a swap function. Don't put the intelligence into the holder of the type(which in this case would be a range). For simple types, a complex swap or property interface isn't necessary. I hope that was clear, it's hard to express what I'm trying to say... -Steve
Jan 26 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 27 Jan 2009 01:52:26 +0300, Steven Schveighoffer <schveiguy yahoo.com>
wrote:

 "Andrei Alexandrescu" wrote
 Steven Schveighoffer wrote:
 I guess I'm not really sure what the "acquire" method does.  I saw you
 mention it in another post, but with no explanation as to what it
 actually does, just that it was needed.  I'm sure I'm not getting what
 should be obvious, but if you could enlighten, I would appreciate it :)

Say you have an object obj that has a Matrix property and you have a Matrix object handy. The Matrix is rather resource intensive so you'd rather not copy it unwittingly. Conventionally, if you say: Matrix m; ... fill matrix ... obj.matrix = m; then m is copied into obj.matrix (there is the by-value call to set property). Now it's possible to arrange things such that m is destructively copied, but as the auto_ptr disaster has shown, it's not that intuitive to make assignment destroy the right hand side. So we'd need a distinct method: obj.matrix.acquire(m); That method takes the matrix by reference, sucks its life out of it, and leaves an empty shell behind. Pretty much like in your average horror movie.

So what you are saying is that you want to control the set such that it destroys the source (essentially, I'm reading, you don't want to do a deep copy, just a reference copy, and then null the original reference). Let me ask another question then... does a property have reason to have both set AND acquire? More specifically, does a function that takes a property as an argument as we have been discussing need both set and acquire passed to it? If not, you can simply pass the set method that you want, still only requiring a pair of functions. How to signal that to the compiler easily? Not so sure... but it does seem to me like a type should know how it should be copied, and likely doing it other ways should require special methods. I can think of possible library solutions to this, say a wrapper property struct that can call any two functions to do set or get.
 Having the two functions seems like a reasonable baggage compromise, if
 you want to control the get and set methods of a property and pass that
 control to an underlying function, you need at least that.  If we start
 generalizing it to anything, then it starts looking like struct
 interfaces would be more suitable.  For example, you could allow  
 setting
 an int property using both an int and a string, do you want to pass  
 both
 setters to a function?  I think limiting it to just a set and a get
 function should be sufficient.

With only get and set I can't implement a nothrow swap, which kinda bends me out of shape.

Sorry, don't get that either. Why can't set and get be used in a nothrow swap? -Steve

Because set implies data copying (read: allocation) and copy constructor call, both of which can throw. How about the following - you call a swap with a dot syntax: int x = 42; int y = 13; x.swap(y); // calls global void swap(T)(ref T, ref T); or a specialized version, swap(ref int, ref int); User is, however, free to implement his own swap method: struct BigInt { ... void swap(ref BigInt other) { ... } ... } Or another way - "void swap(T)(ref T lhs, ref T rhs);" tries "lhs.swap(rhs);" first, and falls back to "auto tmp = lhs; lhs = rhs; rhs = tmp;" if no lhs.swap method is defined. This way you can define "void aquire(ref T newOwner, ref T data);" as "newOwner.aquire(data);" and fall back to "swap(newOwner, data); release(data);" on failure. "void release(ref T obj);" tries "obj.release();" first and falls back to "swap(obj, T());" or "obj = T();" on failure.
Jan 26 2009