Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
Summary:
In the case when you have multiple future in flight related to one object, you
couldn't use the previous version of efl_future_then. Now all function calls
take a void* pointer that allow multiple future to have their private data
request data accessible in all the callback.
This should not break released API as Eo.h is not released yet and so
was efl_future_Eina_FutureXXX_then.
Depends on D7332
Reviewers: felipealmeida, segfaultxavi, vitor.sousa, SanghyeonLee, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7472
Differential Revision: https://phab.enlightenment.org/D7379
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
On destructor we're not supposed to emit events, I even thought that
would be implicit, but it's not. If we do, for example an event
handler that would 'efl_del()' on "EFL_IO_CLOSER_EVENT_CLOSED" would
trigger too-many unrefs.
If we want to upgrade a dialer, then we must have a way to know if
that socket has already adopted another socket so we don't create it.
We can't simply use efl_net_socket_ssl, otherwise we'd miss some
methods such as efl_net_dialer_address_dial_get() and events such as
connected.
in the previous commit we're manually upgrading an existing TCP socket
to SSL. It is desired since some protocols need to negotiate, like
STARTTLS and the likes
Now we offer 2 classes that does autostart SSL once the socket is
ready.
Vincent Torri
Mike Blumenkrantz
Marcel Hollerbach
Cedric BAIL
Daniel Kolesa
Guilherme Iscaro
Gustavo Sverzut Barbieri