2017-09-28 17:53 GMT+09:00 Jean-Philippe André <j...@videolan.org>: > Hello, > > I made a few commits related to ownership and whatnot... you might want to > have a look at them to double check I got it right. > > Basically 2 things: > > 1. A new API to allow unref to delete an object, even if it's got a > parent. This is for APIs that return @owned EO objects (eg. efl_input_dup). > In that case I imagine that C++ should NOT add a new ref (in eo_concrete > thing) when receiving an @owned object (not sure how to do that, > practically). > > 2. Removed @owned from most of Evas APIs as we don't transfer references. > The only thing that may happen is that the new evas/elm parent decides to > delete the object. But from a bindings POV, no reference should be passed > around. > > Finally, efl_del() should work just like evas_object_del() when dealing > with Evas object, i.e. it hides and requests deletion. Any dangling ref > should keep the data alive, albeit detached from any valid parent. > > I hope I got it right, this time. > > > Slightly unrelated, but, I figured out how to return a @owned in C++, and it's basically just changing: ::efl::eolian::return_traits< ::efl::input::Event>::type dup() const;
to: ::efl::input::Event dup() const; And in the implementation, cast __return_value as: return ::efl::input::Event(__return_value); Right now I think this API is the only API returning an @owned EO object. -- Jean-Philippe André ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
