The objects we are implementing here are just a newtype over a raw pointer with no Drop (as the objects are managed internally by IUP). So prehaps they should be Copy?
Currently it does not implement Clone either and there is a fn dup(&self) -> Self; in the Element trait for that purposes, this should probably be removed when this issue is resolved...
The downside I see by using Copy is that it might look like we are not dealing with a object. And the downside I see by using Clone is it gives a look of deep copying the entire object but we'll just be copying a loose handle.
However I see a huge upside in using Copy, we'll not need to wrap the objects in a Rc<RefCell<_>> and add a scope, and add a clone call for every closure callback that wants access to those as seen in the counter.rs example (and seen worser in the older counter example).
The objects we are implementing here are just a newtype over a raw pointer with no Drop (as the objects are managed internally by IUP). So prehaps they should be Copy?
Currently it does not implement Clone either and there is a
fn dup(&self) -> Self;
in the Element trait for that purposes, this should probably be removed when this issue is resolved...The downside I see by using Copy is that it might look like we are not dealing with a object. And the downside I see by using Clone is it gives a look of deep copying the entire object but we'll just be copying a loose handle.
However I see a huge upside in using Copy, we'll not need to wrap the objects in a
Rc<RefCell<_>>
and add a scope, and add a clone call for every closure callback that wants access to those as seen in thecounter.rs
example (and seen worser in the older counter example).