On Fri, Sep 23, 2016 at 11:03 PM, Carsten Haitzler <[email protected]> wrote:
> On Wed, 21 Sep 2016 11:10:00 -0300 Gustavo Sverzut Barbieri
> <[email protected]> said:
>
>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen <[email protected]> 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.
>> 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.
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".
>> 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
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
