28 Apr
2013
28 Apr
'13
8:24 p.m.
On 04/28/2013 09:31 PM, Vicente J. Botet Escriba wrote: > Le 28/04/13 20:17, Pierre T. a écrit : >> On 04/28/2013 07:30 PM, Vicente J. Botet Escriba wrote: >>> Le 28/04/13 18:27, Pierre T. a écrit : >>>> On 04/28/2013 05:20 PM, Vicente J. Botet Escriba wrote: >>>>> Le 28/04/13 16:22, Pierre T. a écrit : >>>>>> On 04/27/2013 03:30 PM, Vicente J. Botet Escriba wrote: >>>>>>> Le 27/04/13 09:39, Pierre T. a écrit : >>>>>>>> On 04/26/2013 08:17 PM, Vicente J. Botet Escriba wrote: >>>>>>>>> * Default Constructor or constructor from nullexpect >>>>>>>>> What is the advantage of having a expected instance that doesn't >>>>>>>>> have >>>>>>>>> neither a value nor an exception? >>>>>>>>> How would the user manages with this possibility? >>>>>>>>> Are you looking to make expect movable? >>>> >>> Humm, I don't know if this is enough. >> I'll drop the default constructor for the moment. When an >> implementation will be available, feedback from users will help to >> find relevant use-cases. >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> *Ah I think I see now what was the initial intention. I >>>>>>>>>>>>> suspect >>>>>>>>>>>>> that you mean that as the result of e.then(f) would >>>>>>>>>>>>> transport the >>>>>>>>>>>>> exception stored on e if e is not valid, then the exception >>>>>>>>>>>>> would >>>>>>>>>>>>> be relayed until there is a call to visit_error and no call to >>>>>>>>>>>>> any function will be done. >>>>>>>>> >>>>>>>> >>> Humm, in the example I gave above f an g are not continuations but >>> expected<> producers. >>> Anyway, the variadic version of then could have its uses. I like it, but >>> it is orthogonal to the when_all feature. >>> >>> What do you think about letting the continuation returning an >>> expected<>? It has the advantage to allowing the continuation to >>> transport exceptions also without throwing. >>> >> I forgot to claim the change but in my "then" version, the function >> passed to "then" must return an expected (or void). So all functions >> are expected producers. It's strange to return something else because >> it would always be a good value into an expected. The "then" chaining >> could not return error cases. >> >> I don't think there are much differences between when_all and then(f,g). > There are some :) > * when_all() is a free function, expected::then is a member function. > * when_all() takes expected as parameters, while then() takes > continuations having as parameter the expected value. > > They have in common that the result could be an expected. IMHO, a member method is better because it can be chained any where in the chain. I also prefer the method taking continuations as it enables void return function. >> >> However, I propose to let this feature out of the GSoC proposal. But >> of course, we wouldn't let it out of the summer, it's just because >> time is lacking and adding features in a hurry could break the >> proposal consistency. > You could add them as COULD features if there is enough time (not on > plan). I would prefer if these features were in the priority SHOULD. > BTW, could you classify the features of your proposal as MUST/SHOULD/COULD? Of course, it's an excellent idea. I'll try to update my proposal by tomorrow. >> >>>> About the "inspect" method, I try to find another name instead of >>>> visit_error because it makes me think to the pattern visitor which is >>>> too specific to hierarchy classes. I found that inspect was nice >>>> because it's like in a factory where the chief "inspects" that >>>> everything has been alright. >>>> >>> The name should work independently of the name of the 'then()' function. >> Oh nice remark. >>> >>> on_exception? if_exception? catch_all? capture? >>> >>> >>> >> I would say "on_error", so it would be a generic name for error type >> that aren't exception. >> >> > yes, why not? > > Best, > Vicente > Best regards, Pierre T.