On March 20, 2018 6:14 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 20 Mar 2018 12:06:08 -0400 Cedric Bail ced...@ddlm.me said: > > On March 20, 2018 7:38 AM, Carsten Haitzler ras...@rasterman.com wrote: > > > On Tue, 20 Mar 2018 10:06:43 -0300 Gustavo Sverzut Barbieri > > > barbi...@gmail.com said: > > > > <snip> > > > > > > I said I'd give up... but seeing this makes me sad. > > > > in two lines you: misused the Eina_Error AND missed the purpose of > > > > resolve. > > > > > > > > I hoped when you looked at it, written as code, you'd realize the > > > > mistake... but seems not... so I'm pointing here. > > > > > > > > eina_error conversion to string (which will be helpful to high level > > > > languages) is missed, "+ 1000000" is an error that is not > > > > registered... > > > > > > > > OTOH success is always ZERO, so there is no value... IF that would be > > > > right, then it should be a void promise (carries no value). > > > > > > > > but my hope is that you'll simply move this to > > > > eina_promise_resolve(pd->promise, eina_value_int_init(exit_code)) > > > > > > > > and listen to my advice that is to move the "!= 0" OUTSIDE of this > > > > function, you're mixing roles :-/ > > > > > > eh? we only have 1 value to know of success or failure. an int. 0 == > > > success. anything else is failure. that's precisely what i did right > > > there. > > > > No. Think about what Eina_Error mean for binding. It will trigger an > > exception in some language. Now the user as to catch exception and instead > > of > > doing a switch on expected real error, it has to work around this hack to > > get > > the real exit status. Additionnaly, there is no requirement/guarantee in > > Eina_Error that this error code will never be used for something else. > > i'm not the one coming up with raising exceptions or not, BUT i mentioned this > before. shell: > > cmd1 && cmd2 && cmd3 > > is a chain of promises. they are the same thing. if cmd1 succeedsm then run > cmd2, if that succeeds run cmd3. if the "it doesnt succeed" is done via an > exception - then promises are going to SUCK.
Great example. This is not a chain of error/success, but a logical and operator, the same way you would do in C : if (f1() && f2() && f3()) A chain of future is not designed to just implement the above line, but you should be able to do also : do || fallback or even : [$? -ne 5] In all of this case, it is using $? value explicitely or implicitely. It would be the same in C, a value. So during a future resolution is when you take a decision on what to do with the value, should it be a &&, ||, -ne, -eq or whatever. future/promise are a generic construct, they are not supposed to just handle the shell && command. > if a file download failed to fully complete - exception. if a file_set failed > because file doesn't exist - exception. you do know that there is tonnes of > code in e and efl that does a file_set to just determine if the file exists > AND > is an image or not? (well file_set then size_get for non 0 size). if > exceptions > are the way to do this then there are going to be a LOT of them and people > have > to handle them in that language. Some language implementation of future and asynchronous primitive, like for example Javascript, do not have a failure case. To generate a failure, you throw an execption and you catch it at the end of the future pipeline. That's how it work. So yes, in some language, you have to deal with exception. And the interface should document the expected exception at some point. > if exe's can never fail - they always succeed unless there is a total > catastrophic failure (fork or something before fork fails - highly unlikely) > then you can never use promise chains to run a series of commands one after > the > other. If you actually return a value, you can actually make series of commands with all the behavior you want more easily. How about doing something when the exit code is 5 ? future are a generic construct, not their to do only the equivalent of &&. > something has to make a decision on failure and promises make that decision > when it's rejected, and the point of rejection is exit code. the shell already > decided on this. cmd1 && cmd2. Yes, your code in the future or as Gustavo proposed, we can have helper that check for this value and provide operator logic that you can insert in the pipeline. I hope that help you understand why a process exit code is a value. Cedric ------------------------------------------------------------------------------ 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
