As framework developers we should be doing everything in our power to avoid undefined behaviour. I’ll take accidents memory leaks any day - there are a plethora of tools to solve that but it’s far harder to debug the “app not working correctly sometimes on my system” bug reports.
Andy On Sat, 23 Dec 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com> wrote: > 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 > > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ 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
