Please don't kill _del. A documentation fix or guarantee on what it deletes would be nice[1] (I recall it used to delete the most recently added item that matched).
Del allows you to remove a callback without having to keep track of the data pointer, which is useful, if you know the lifecycle of the datapointer is safe. In particular since the name of the callback is a global name it is easy to discover/keep track of, but the data pointer would require extra access. Regards, nash [1] It may be there, in either case, not relevant to the topic at hand. On 10 February 2015 at 09:16, Tom Hacohen <tom.haco...@samsung.com> wrote: > Hey, > > I'd like to raise another issue which has been bugging me for a while > and I was just reminded of thanks to T2077: > evas_object_event_callback_del() and the such. The failure cases are not > that common, but they can happen. This API is already gone in Eo. > > So what is it? > There are two ways to delete a callback: del() and del_full(). > The former accepts type and function, the latter type, function and data > pointer. As you can guess from the signature, del() doesn't take the > data pointer into account. > This means, that this code: > add(TYPE1, func1, data); > add(TYPE1, func1, other_data); > del(TYPE1, func1); > is undefined. > > This for example could manifest if there's a general helper function > that can be used as a callback for some common operations (with a > different data pointer that controls the behaviour) used by two people > controlling the object. A very good example would be a widget adding a > callback on itself and edje/the user/elm doing the same. Another good > example is if two different parts of the code implement filtering on an > entry using callbacks and use the same helper (regex helper?) function > with two different data pointers. > > We are obviously not going to kill this API before EFL 2.0, but it's > better I'd like to mark it as deprecated, to at least prevent new > usages. We'll have to deal with the newly added warnings as we go, as I > suspect there'll be some uses across the EFL/enlightenment (I'll do my > best fixing all the ones I can without deep understanding of the code). > > Any thoughts on the matter? Please don't +1/-1, thoughtful replies or > none at all. :) > > Thanks, > Tom. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
