On 12/05/16 13:58, Tom Hacohen wrote: > Hey, > > This email assumes some knowledge of Eo in order to keep it short. > > > eo_del() was introduced partially as a continuation to what was in evas, > and partially as a solution to circumstances that no longer apply. In > short, it is no longer necessary to have eo_del() as separate from > eo_unref(). > > In Eo, parents have a reference to their children that they own. > eo_del() at the moment unparents if there is a parent (which in turn > unrefs) or just unrefs if there isn't one. That is, it is the > counterpart to eo_add(). > > It is illegal in eo at the moment to unref() an object to the point of > deletion if it still has a parent, so "eo_add(CLASS, parent); > eo_unref();" is illegal. > The problem with that is that you now in some cases need to understand > if you want to call del() or call unref(). This distinction adds > complication and doesn't add any significant safety over just allowing > to unref. > > > Therefore, I suggest we just allow unreffing the last ref (the parent > one) with eo_unref() which will implicitly unparent the object as the > correct legal way of deleting an object. Essentially this mean we define > that the parent reference is shared with the programmer. > > > Do you have any objections or concerns about this? It cleans up some of > the handling with proxy objects, and in general it just feels more > correct and will make things simpler. > > > > Somehow unrelated: while eo_del() wasn't used this way, there is a good > reason why to have an eo function that is somehow equivalent to eo_del() > but behaves differently (more in the way raster wants del to behave). I > would call it eo_halt() though a better name may be needed. eo_halt() > has nothing to do with object lifecycle. It doesn't ref or unref or > doesn't do anything of that kind. All it does is "halts" the object in a > class specific way. So for example, for Efl.Network, it will stop all > traffic and kill the connection (but will keep the object alive), for Ui > objects it will hide them, maybe unswallow them, but will keep the > objects alive and etc... > > > What do you think about the two ideas? I will probably also mention them > in my talk, but I'd love to hear some feedback before so maybe I can > just make the change.
No significant objections on the ML and only agreements in person so I went ahead and implemented it. I only implemented the eo_unref() changed and the removal of del(). No eo_halt() yet. -- Tom. ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
