On 13/02/15 07:41, Adrien Nader wrote: > On Tue, Feb 10, 2015, Tom Hacohen wrote: >> On Tue, Feb 10, 2015 at 8:00 PM, Brett Nash <n...@nash.id.au> wrote: >> >>> 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. >>> >> >> The problem with this is that even if you guarantee the deletion order in >> the docs (that is, most recently added would be deleted first) and make it >> 100% obvious in that regard, it's still not safe. You can never be sure >> someone else hasn't added a similar callback with different data after >> you've added yours. As I said, this is an uncommon occurrence, but it'll >> become even more relevant once we start using the callback mechanism with >> more "global helpers" like we plan on doing on entry with string validation. >> Even without the global case, it's a recipe for trouble in people's code >> when they mismanage the order of callbacks added. >> >> We are becoming more and more protective of our developers, for example >> with eo pointer indirection, we wouldn't like to make sure they don't shoot >> themselves in the foot, and I think having this function available is a >> threat to that notion. >> >> Sure, it's easier not to manage that, but it's sloppy. > > And it's what people use more than 99% of the time (well, 99% is > probably too high but I'm confident in 95%).
But it's horrible. > > Maybe ERR() when _del() is used while there are several callbacks set > up? Or give it a stack behaviour where the last installed callback is > removed (I think I might actually have relied on that but I don't have > access to the codebase anymore). As I said, this stack behaviour doesn't help at all, because 1. it's harder to manage order over keeping the data parameter. 2. you don't know if someone else (inside the widget?) added the same callback. Anyhow, I'd say that in 99.99% of the cases where the data is not a constant, it'd need memory management (freeing) anyway, so the pointer is already kept and you might as well use it... > > There's a saying about making the complicated tasks possible but keep > the simple tasks easy to achieve. I think it really applies here. > I completely disagree. Deleting with the data is not a complex task, and deleting without the data is not a simple task. Those are not two different features, what we are talking about here is making one task (callback deletion) safe for users. -- 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
