On Mon, 26 Sep 2016 16:24:36 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> On Fri, Sep 23, 2016 at 11:03 PM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Wed, 21 Sep 2016 11:10:00 -0300 Gustavo Sverzut Barbieri
> > <barbi...@gmail.com> said:
> >
> >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen <t...@osg.samsung.com> wrote:
> >> [...]
> >> >> promise/future should be first-class citizen... as well as iterator
> >> >> and the likes. There is a start already, but refinement is really
> >> >> needed, like returning an iterator<x> should handle warn_unused, free,
> >> >> own... Promise should have its own callback signature, simplified for
> >> >> the user.
> >> >>
> >> >
> >> > They can, be, but they will just be provided by Eo. There's no need for
> >> > any special treatment in Eo.
> >> >
> >> > Promise signature: you don't need to do it in Eo. I mean, you can add a
> >> > special type in Eolian, but Eo itself need not be aware. Also, I
> >> > disagree.
> >>
> >> Do you mean still use Eo's events to dispatch promises?
> >
> > yes. when we had eina_promises i instantly just c&p'd the eo event cb to
> > write a success and failure handler and "boom type mismatch" ... wtf? i now
> > had to go look it up. PAIN POINT right out of the box.
> >
> > 90% of the time people only will care about success or failure. the other
> > 10% they want the value IN the promise. you can get that from the eo event
> > info. i actually think you just should "get" the value from the promise
> > object anyway as it stores it...
>
> why is that? I know our APIs, particularly Evas and Elementary worked
> around the 'void *event' signatures by producing no "value" in the
> callback, instead forcing you to query that yourself. Like "canvas
> resized", then you must query the information "whats the new size?".
>
> But if promise delivers the result in a nice way, we should be
> providing more values as payload.
promises do deliver values in the event info. in there... but i just dislike
this when you can query the promise itself for that in the cb or at any time in
the same way inside or outside that cb.
> >> I don't get why Efl.Promise is an Eo at all. Looking at the code shows
> >> now hints of benefits. Asking Cedric leads me to an awful answer...
> >> :-/
> >
> > because when it was an eina_promise it did everything an eo object did. it
> > had event callbacks (succeed/fail), it had progress event callbacks, it
> > stored values, could be ref and unreffed, and more and more. it looked
> > exactly like an eo object but just was an eina promise with its own custom
> > api instead. it just made no sense. there is a whole big long thread on
> > this in history you missed. you might weant to go back a few months for
> > "promises" subjects and see.
>
> this is because, in my opinion, they tried to do too much for too
> little value. Allowing multiple then callbacks for a single promise is
> like that, you need a list of promises, you need to keep account if
> you're walking the list... if the promise was deleted from a cb, etc.
well the referencing was needed so you can cancel a promise as you now need to
store it as an object/handle to access later to cancel it. so cancellation
really created the need for it to be an object. so it shouldbe a real object,
so if i delete the promise it is canceled and then i can attach it as a child
object to my parent so if parent is deleted the promise is too thus cancelling
the action i no longer need with no extra code from me. :)
> if it was kept simple as in other implementations "1 promise = 1 then
> + 1 error", it would be much, much simpler. There is no ref, no
> unref... If an object returns a promise, the object itself will have
> to keep the pointer to deliver an output value (even if "void", to say
> it was fulfilled), thus you know when you get cancelled, and you know
> when you fulfill or reject.
>
> There are 2 PoV to that: promise returners and users.
>
> returners, or objects that return a promise, will create it and either
> fulfill or or reject it. They can pass one CB to be informed if the
> user cancelled the promise as its not needed anymore. The returner
> does all the memory allocation and free.
>
> users are those that do "then" and "else" (or "on error"). Then is
> called upon fulfillment. Else (or on error) is called upon rejection.
> The only operation an user can do on a promise is to cancel it (which
> will report back to "returner" as per above). No memory management on
> the promise itself is done. Calling "cancel" will call its own
> "else/on error".
and this is what REALLY necessitates an object. promises are objects in js for
example.
actually. i don't want to re-hash this thread. go back to the original one on
promises. :)
> >> The promise thing should only be a thin layer that forces a clear
> >> pattern: wait for data, deliver data or call failure. I don't get why
> >> in the other thread people were talking about references in promises,
> >> inheritance, etc.
> >
> > that's not what they were. they were full on objects with referencing and
> > lifetimes etc. and reality is they actually need to be as you need to keep
> > the promise handle around so you ca CANCEL it. there are cancel methods.
> > this requires a lifetime and referencing. thus. eo objects.
>
> not really, see above.
>
> The API for promise returner is simple 3 methods:
>
> Efl_Promise *efl_promise_new();
> efl_promise_fulfill(p, value); //does free
> efl_promise_reject(p, error); //does free
>
> The API for promise user is also simple:
>
> Efl_Promise *efl_promise_then(p, on_fulfill, on_reject, data);
> void efl_promise_cancel(p); //calls efl_promise_reject() and thus
> on_reject() and frees the data.
>
> no ref/unref, nothing complex. If there is a single CB per promise,
> then its simple. If there are multiple CBs as Felipe/Cedric want,
> you'd need to keep a "walking" counter + deleted flags to avoid
> messing with the list while its being walked. I don't think its worth.
>
>
> >> While the API is what it should be, it's PITA to use. If we could
> >> extend the generator to do those for us, we'd have to implement only
> >> high level functions. Like it does for C++ or Lua bindings, do to C
> >> "user code" (could also do C++/Lua user code as well). Example:
> >>
> >> myapp.eou: # eou = eo user
> >>
> >> objects {
> >> xpto { /* creates an object called "xpto" */
> >> children {
> >> window { /* window is part of xpto, it will be created using
> >> given type and properties */
> >> type: Efl.Ui.Win;
> >> constructor {
> >> type: Efl.Ui.Win.Type.basic;
> >> title: "hello world";
> >> }
> >> events { /* these will be connected for you, callback
> >> handlers are expanded based on event payload */
> >> resized @proxy; /* proxy = will forward this event as
> >> "xpto" using the same name */
> >> delete,request; /* user must implement the callback
> >> with handler */
> >> }
> >> }
> >> box {
> >> type: Efl.Ui.Box;
> >> }
> >> label1 {
> >> type: Efl.Ui.Label;
> >> }
> >> label2 {
> >> type: Efl.Ui.Label;
> >> }
> >> entry {
> >> type: Efl.Ui.Entry;
> >> }
> >> }
> >>
> >> connections {
> >> entry: changed -> label2: text.set; /* somehow like Qt's
> >> signal connection */
> >> }
> >>
> >> composition { /* basic method calls using other objects and
> >> constants */ box.pack_align(0.5, 0.5);
> >>
> >> label1.hint_align.set(0.0, 0.0);
> >> box.pack(label1);
> >>
> >> label2.hint_align.set(1.0, 1.0);
> >> box.pack(label2);
> >> box.pack(entry);
> >> }
> >> }
> >> }
> >
> > yeah,. you want a special ui layout language that compile to c :) it could
> > do mroe than just declarative ui and glue in callbacks like promises etc. -
> > it would need to glue in event cb's anyway for clicked or changed events on
> > widgets. but this is orthogonal to promises.
>
> indeed its orthogonal to promises. But it's not an UI description
> language, its to save me from typing and doing errors, resolving all
> the class hierarchy myself.
>
> you could as easily read that GUI example as network, where you create
> an input, output and a copier, link them together, configure some
> properties and then have it to be executed.
>
>
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
