On Sun, 12 Jun 2016 11:02:37 -0700 Cedric BAIL <[email protected]> said:
> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler <[email protected]> wrote: > > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL <[email protected]> said: > > <snip> > > >> >> You just can't do with eo event what promise do. Eo event are a > >> > > >> > it's not NECESSARY to do anything new. timeout can be an eo obj that > >> > deletes itself after the one-shot callback. it doesn't need a promise. > >> > same as job. i can't add promises as children to an obj and make sure > >> > they get autodeleted when parent is. i have to do this all by hand now. > >> > >> It is a terrible mistake to override eo object lifecycle. This is an > >> absolute no go as a solution. Anything that bypass the refcounting and > >> ownership of an eo object lead to massive issue and trouble. We can > >> not implement auto deletion of eo object outside of the reference > >> count system. > > > > this doesn't bypass it. it USES it. the object unrefs/del's itself. when > > done. when an evas canvas is deleted it deletes all child objects. no code > > is explicitly in the app deleting the objects. it's done internally. > > That's exactly what I mean by bypass. Evas canvas delete object > because the parent die. Now, in the case of a promise eo object, there > is no parent that will disapear to do the unref/del, it is when all > the listener have received the value, that the promise disapear. If > you want to use normal eo lifecycle for that, it means that the object > has to delete itself. And this is bad. This is exactly what > ecore_timer where historically doing. They were not linked to any > parent and would just vanish under your feet. This is what tricked you > into thinking the bug was in the timeout promise while it was in the > handling of the lifecycle of the timer itself. and for promises its the "parent action" the download, the async property fetch, the file load etc. that is the parent conceptually and it deletes the promise representing it in the wild. > Reading what you say, you are advocating for using the normal eo > lifecycle and not letting itself commit succide, which is the proper > way to handle eo object. Now how can that work with promise ? No idea. YES I AM. as jp already said. we have proxy objects that self-delete on first use in another function. promises self-delete when the action is done - same idea. of course it can work. it works just fine. we do it already. there is no "proper way" to handle eo deletion other than objects ARE deleted. the convention is parents del children. del otherwise can happen anywhere by anything. there is no magical rule otherwise. <snip> > Promise are a promise to deliver something in the future. In themself > they have no propery and no function. They aren't object, they are of course they are an object. they old a success/error callback. they HOLD the value content until suhc a cb can be set to get the value. they can be ref'd and unref'd and kept around for along as desired. in js, c++ and lua they are actual objects because these languages ONLY have an object, or a basic variable. so they are objects there. you keep the object around so you can cancel it. they are objects. they are as much objects as eo objects are. > delivering object. Their lifecycle is that they either deliver or > fail, they never "die" before that. It is a guaranty that they deliver > a callback whatever happen to everyone that registered to listen them. > This doesn't match at all eo object lifecycle. proxy objects. need i say more. they die after first use in another func. and either way this is a lifecycle SPECIFIED by the promise object. it is HOW they are meant to work. they are MEANT to delete themselves when done (after calling success/err callbacks). self deletion isn't something eo forbids at all. > > you are totally inconsistent thinking promises are some kind of magically > > special thing that is not an object... yet in all ways it works *IS* an > > object. > > If you stretch the definition of an object outside of what Eo is, yes, > but by that standard everything could be an object. If you limit your > definition to what Eo is and I mean by that Eo lifecycle and events, > it doesn't. Oh, and there is plenty of stuff in an Eo object that are > useless for promise. eo doesn't define an object cannot self delete. so it matches. eo events are not useless for callbacks - its how you can extend progress etc. it makes far more sense than what eina_promise has now. it allows inheritance and extension. eina_promise is totally fixed in stone. and so what if key/value data is not useful. it doesnt cost anything except a ptr to have as a feature and all eo objects have it and its not useful on every single object BUT... it's useful ENOUGH to be in the base class. so what then? a promise uses a bit more ram. this isnt about ram or efficiency but of usability and eina _promises are FAr LESS USABLE than if they were eo objects. the little extra cost and extra features are a more than easily payable price to get the usability. <snip> > > why do i not want them? tell me? why do they even exist then as an idea and > > why are they in eo? if i want a weak ref then that's what i want. i want a > > handle that the object system will set to NULL for me when the obj is > > deleted so i don't have to do that by hand by adding a del callback and > > nulling the ref myself. so... why don't i want them? i can tell you that e, > > efl etc. is full of this kind of "track del event and NULL a ptr" code. > > it's all over the place. so... why? > > Because you are only interested in the result of the promise, not in > the promise themself. You don't track the life of a promise, because WRONG. jobs are promises. i HAVE to track their lives. i HAVE to be able to cancel them. timeouts are promises. same thing as jobs. efl itself has 95 instances of ecore_job_del. terminology has 9. rage has 4. don't tell me all those instances of ecore_job_del never had to track the object and handle its lifespan? thats EXACTLY what promises are replacing in addition to much more. you DO care about the promise itself. without doing so you cannot cancel it. maybe you don't want to cancel it at times, and at others you do, BUT you need to have a promise object to be ABLE to cancel it. > you do that the moment you register the then/cancel callback on it. If wrong. see above. > you do not need the result of the promise, you cancel it and that is wrong. see above. you may cancel it when the object needing the promise no longer needs the job or timeout. that is EXACTLY what you want and when this happens will be the result of some other event/state change. that's why eo_del should just cancel a promise imho (or just going to 0 refcount). no need for a special cancel call. i ecore_job_del or ecore_timer_del and the object dies and it no longer calls anything. it's been logical and worked for years. why are promises so different/special that they don't need the same thing? if they are replacing some timers and jobs ... then they obviously need the same behavior. now if they were eo objects i just have to make them a child of the owning object and when that object dies (eg window closed or widget deleted) the promise will be magically deleted and thus cancelled for me. without any extra work. with eina_promise i have to always manually do this myself. it's bad usability-wise as opposed to if it were eo. > the same as if an error did happen. As said before, we may need a way > to automatically cancel a promise once an object is deleted, but you why come up with new magical ways. we have it already - eo. just make promises eo objects! > do not need to keep a promise around because an object is still alive. > That's because the object is not using the promise, it is expecting > its result. Something along eo_promise_link(obj, promise) is the only > thing we need. no. see above. in addition to cancelling jobs most of our timers are timeouts. all the ecore_timer_del's across efl, terminology and rage are about 400 of them. yes the promise objects need tracking so they can be cancelled when not needed anymore. 2 ways to automatically do this are: 1. add as child 2. add as a string key -> obj handle in the key-value properties of another object (and unref after this kiving the key the remaining handle). if the object with the key is deleted or the key is replaced/deleted the object referenced is unreffed thus magically a promise can be canceled without extra code that you now say we have to come up with". we donb;'t have to come up with yet more mechanisms if you just have promises be eo objects with specific lifetimes like proxy objects. > <snip> > > >> when handling asynchronous stuff). And implementing that behavior in > >> Eo is going to be a pain (disabling refcounting, disabling > >> parent/child, ...). > > > > eh? don't disable refcounting. in fact WTF is this?... > > > > EAPI void eina_promise_ref(Eina_Promise* promise); > > EAPI void eina_promise_unref(Eina_Promise* promise); > > > > you speak of not refcounting yet eina promise has RE-IMPLEMENTED reference > > counting just like eo. i can't take what you say here seriously. if you say > > promises are not objects and should have no reference counting because they > > are oh so special yet... right there in eina_promise is EXACTLY THAT. eina > > promises are re-inventing eo objects thinking they are oh-so-special > > not-object-objects. > > This is the refcounting of how many callback then/cancel are to be > registered and a protection against deletion when running them. This > is not like eo_ref/unref as they do not refcount the same kind of > thing (number of user vs number of callback waiting for a result). doesn't matter. it's still a reference system - yet another one when we have it already in eo. <big snip - kind of bored of going in circles> summary: eina_promises must become eo objects. eo_promise. extend basic then/else cb's with eo events. then/else can use a special method (like eo_promise_then (promise, cb_done, cb_err, data);) that's manually bound. they are not any more special than any other eo object and having a whole new object api and ways of gluing it in specially just to avoid it being eo is wasteful of code, time and of the sanity of programmers using efl's api. they are full normal objects in c+ +, js, lua etc. anyway and that doesn't seem to be a problem for you given the fragile state of promises at this point. by fragile i mean new, untested, buggy, not well beaten into shape by actual daily use like eo itself has been for the past years, we should minimize use of promises so we don't create a big problem for ourselves. at least until we have sorted them out and are happy with them. and then use them very very very carefully. likely extend efl api to then have promise using versions of api;'s other than a very few that we used for testing - when that day comes. for efl 2.0 we can have the "promise only" versions if that works. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
