Hi, First +1 :P
On 02/10/15 19:16, Tom Hacohen 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 > Between removing the first registered, the last registered and the highest priority, I prefer the last registered, i.e the behavior that was before adding the priority feature. Even if I am ok to remove/deprecate this unpredictable function, we should at least give it a behavior that could have some logic. And removing by priority doesn't sound good to me, as the first registered (this one is mine ;-)). So +1 +1 +1 JackDanielZ, alias D2 ------------------------------------------------------------------------------ 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
