On Thu, 12 May 2016 13:58:42 +0100 Tom Hacohen <t...@osg.samsung.com> 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. As one of the actual users of eo, I'll have my say. Sounds OK to me, but I could be convinced the other way. The names are the only thing that worries me. You add something with eo_add(), but delete it with eo_unref(). Should be add/del or ref/unref. Makes no sense to unref something you never reffed, even though I understand the ref was internal to the add. As for other names for eo_halt - eo_whoa_nellie? eo_GTFO? eo_YOU_YES_YOU_BEHIND_THE_BEDSTEAD_STAND_STILL_LADDIE (best yelled in a Scottish accent)? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
