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...
> 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.
> 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.
> >> AND if possible, make eolian or a new tool to handle connections for
> >> us, if it was easy to declare objects with composition of
> >> events/promises, it would save us lots of typing and errors.
> >>
> >>
> >
> > I'm not sure what you meant here.
>
> the process of creating and object, setting its properties and
> connecting events is painful in C. We need to replicate the whole
> "<NAMESPACE>_${METHOD}(efl_added, ${VALUE})"... for events it's even
> worse.
well efl future is already pretty good:
f = efl_file_set(obj, "blah". NULL);
efl_future_then(f, cb_success, cb_failure, obj);
sure - lambdas would allow the success/failure code to be inline like langs
like js/lua. we actually should consider using lambdapp just to make our own
efl c code more manageable. but either way that above is not that bad. if you
want to handle more (progress, make the promise cancellable safely like keeping
a ref or weak ref around ...) requires another line or 2. but this here isn't
bad for the common case of just success or failure.
> 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.
> Then in my code I'd just:
>
> #include "myapp.eou.h"
>
> static void _xpto_window_delete_request(Eo *xpto, Eo *window) /*
> nothing else as there is no payload in that event */
> {
> printf("window was closed\n");
> }
>
> static void _xpto_resized(void *data, const Efl_Event *event) // or we
> create an xpto_event_resized_add() which unpacks and makes it easier
> to use
> {
> }
>
> int main() {
> // ...
>
> Eo *xpto = xpto_new();
> efl_event_callback_add(xpto, XPTO_EVENT_RESIZED, _xpto_resized, NULL);
>
> // ...
> }
>
> #include "myapp.eou.c"
>
>
>
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (16) 99354-9890
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
