On Fri, 22 Dec 2017 11:53:32 +0000 Andrew Williams <a...@andywilliams.me> said:
> We do have a showstopper design bug. see my previous mail. https://phab.enlightenment.org/V7 to be explicit. discussed. voted on. known compromise. lots of code built on top of that design decision. not a showstopper by any stretch. it's exactly what gtk does. the only difference is we have the "parent set" be part of the add and gtk does it as a separate step with container_add() > We are managing to work with it because we know how it works internally. > The API must be straight forward and provide consistent, robust options. > > Any new user would be asking of efl_add: > *) Do I need to unref the result when I am done? > *) How long is my returned reference valid for? see the vote. see gtk samples. floating reference. > Both of those are answered with "it depends" and that is a design > showstopper. disagree. it's clear. if parent is NULL then calling scope gets a floating reference you have to unref. if not then parent owns that reference and the rules of that parent cover lifetime of that object. covered that in prior mails - the alternative is to force people to manually unref every time they want a handle to something at all to do useful things with ... like add a child to this parent (child packed into a box parent for example). see the gtk/gobject design doc with the idea of floating references. see the previous discussion thread. see the vote in favor of what is there now and with everyone fully aware of scoping etc. and that is why efl_add_ref exists if you choose to use that. note for this discussion i am assuming scope is a small local function scope not larger. technically it can be the global scope of the entire app. i'll put it simply: 1: do it your way and people will have to always unref at end of scope (if they want an object handle to do something with, like pack a button into a box parent which is exceedingly common). the will at times forget to unref causing leaks. 2: do it the current way and perhaps sometimes in some rare circumstances an object is deleted by a parent before your scope ends. chances of 1: i'll put it at maybe 10-20% that someone forgets a scope exit case and forgets to unref (a return in the middle for example). chances of 2: i'll put at at maybe 1% on a bad day. likely far far less. so let's say 15% to 1%. 15x more mistakes likely with your proposal. but let's cover the CONSEQUENCES of a mistake: consequences of 1: leak memory (possibly huge amounts, if for example this is inside a model where you create objects and return them to the model to display but now they return with an extra ref and never get deleted as a result). leaking enough memory will result in severe system degradation (hitting swap or OOM killer) not to mention be relatively hard to pin down where the extra ref came from. a lot of fun debugging this ans isolating it. consequences of 2: a complaint to stderr with the object id, a backtrace to where it's invalid (instantly identifying the point of invalid access and very quickly leading to finding the source). with the identification of the invalid source point, finding the deletion point is very easy by adding a del event callback and tracing that. We could find ways of making this easier with env vars or a convenience call like efl_debug_del_track(obj, EINA_TRUE) which might print a debug log with bt on deletion of this object. you already know the exact object that is creating this issue from the first bt... so this will be a 2nd step to isolate it exactly. much easier to fix than #1 AND the conseqeunces are far less as it's just a "error print". so how do we rate the conequences? well #2 - let's call it a 10, and let's say somethnig vey hard to debug and that could lead to oom killers and swap storms... i'll call that a 1000. so 15*1000 vs 1*10. 1500 TIMES worse. yes. numbers pulled out of thin air. i'm making a point. your proposal is worse. in addition moving from #2 to #1 would be a huge effort to do, lead to a lot of problems in the efl tree for a long time until cleaned up (leaks found and fixed, all the instances done right etc.) thus adding pain, delays etc. etc. and ... who will do it? the majority (~87% of devs) disagree with it option #2. see poll. so most devs will not be keen to do something the vast majority disagree with. is something voted against by 87% of devs and 1500 times worse for the end user worth spending a lot of effort on and adding delays and such pain? > Andrew > > On Fri, 22 Dec 2017 at 10:56 Carsten Haitzler <ras...@rasterman.com> wrote: > > > [snip] > > > > this is the kind of change that would only really justify being done if we > > had > > a showstopper design bug. we do not. not IMHO. there is clear behaviour and > > it's logical and simple. if you don't LIKE it... efl_add_ref is there for > > you > > to use and then to remember to unref on all scope exits by hand. i > > certainly > > would not choose to use this. > > > > [snip] > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
