On Wed, 8 Jun 2016 17:10:07 +0200 marcel-hollerb...@t-online.de said: > Hello, > > On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote: > > > [...] > > they should be eo objects. > > I wondered in the beginning why promises are not a eo object, comparing the > two models shows that it can be dangerous moving promises to a Eo.Base class.
how so? > Take a look at the events, when in a promise the then callback is > called the callback is unsubscribed, and never called again. When a then > callback is attached after the value is set the then callback is called > while beeing added. So this is a completly different sematic compared to > Eo.Base. Of course a implementation can be treated to do smth. like > that, but i think its confusing to users of a api, if objects behave > differently under the same base api. i disagree. having eina_promise_ref in addition to eo_ref, having yet another copy of the oi id indirection to make promise i'ds safe etc. is worse than making a promise live within eo api. as i keep saying - the solution is worse than the disease. we dont HAVE to use eo event callbacks though. we could special case then/else in eo promises and of course require those to be hand bound specifically. eo objects that delete after their task is done can be tagged in eo as such specific objects, just like proxy objects delete themselves after use. it isnt confusing when its tagged. it's just a PAIN to have eina_promise vs eo_* in c. in c++, js, lua promises are normal objects with all normal object operations of referencing, gc'ing, deletion etc. just like eo is for c. in other langs they use the SAME object api as all other objects, why are they so special in c where they should not? all they do is cause pain in c. in other langs they are full blown normal objects as i am saying they should be in c. we can do: eo_promise_then(promise, done_cb, err_cb, data); it's a special manually bound method that has the 2 cb's. all the eina_promise progress stuff can be dropped and done as eo event extensions. any events until the done/err can be extended as much as desired via eo callbaks. it nukes a huge amount of the eina promise api. no need for the progress_cb stuff and only extend where needed and use normal inheritance/classes for this. have a promise progress class for anything needing to extend promises to do progress that inherits from the promise class. and so on... > Also when attaching a then_cb you will get a ref of the promise, so as > long as your then_cb is not called the promise will not be freed. This > is also something which does not play with the ref/unref system of > Eo.Base. see above. and we already define proxy objects to specially delete themselves after their furst use. is this no different to the promise deleting itself after the then/error cb? it's aproprty of the object. it's specific to promises. you have to learn this behaviour with eina_promise objects anyway and in c++, js and lua you have normal "regular objects" that are hiding the eina_promises that behave exactly this way... so the argument that promises are somehow special and cant be eo objects falls apart the moment you are in c++, js or lua where they ARE such objects. so i call the argument "bogus" on the best of days. > Basically you can say, after the then_cb you just have to nuke your > reference to your promise, at the best dont keep a reference to it. we don't need to tell people to nuke their reference. the obj class just does an eo_del on itself after calling the then/error cb. you don't need to. if someone as an extra eo_ref on the obj then it stays alive until that ref is released - this is exactly how eina promises work now. there is nothing weird or wrong with eo objects working this way too. they already do - proxy objects for parts. > So all in all the concept of A Promise inheriting from Eo.Base doesnt > sound sane to me, and looks like a huge confusion you can get in. So I > would prefer to keep the promises as they are, exept the idea of using > Eo_Id to make the pointer more secure. i disagree. think of operator overloading in c++. a + may not mean a mathematical +. i can ave a string lass that makes + append the strings. this is common. it makes a common tool work appropriately for the task. people seem to be able to deal with this. same with eo promise objects. they are objects with a specific behaviour. they delete after their then/error cb is called. they only allow a single then/error cb. you CAN add event cb's to listen for their deletion with del events, or you can extend them with progress cb's etc. there is no reason the then/else cb's have to be a different cb prototype to eo event callbacks. the return value can go unused as there are no more cb's to skip after this so its just a dummy return value. it saves a lot of mental effort to remember the different callback types. the return doesn't hurt as it has no effect. the value stuff can be passed in the event info ptr. > Greetings > bu5hm4n > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------------------------------------------------------ > > 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 enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
