Page MenuHomePhabricator

eo: Make efl_object_override more dynamic
Closed, ResolvedPublic

Description

See T5301 and T5567.

If we start introducing factories and other APIs where the user needs to override some functions, this needs to be dead simple in any language including C as well.
Right now efl_object_override has a major limitation: It can only be done once with a single array of functions. Here are my proposals:

  • Allow multiple calls to efl_object_override, and replace functions as we add new ones
  • Setting a function ptr to NULL means revert back to the original (parent class) implementation
  • All function ptr set to NULL means no more override
  • efl_class_name_get() needs to return not just "Efl.Override" but also the class name of the original object (necessary for debugging!)

The current implementation is what it is now because of fears that overriding functions may lead to undefined behaviour. Also we can not layer multiple overrides, i.e. if a function is overriden once, then we can override it a second time but then the first override becomes inaccessible (efl_super can not support that).

Unless there are good reasons not to apply my proposed changes I will implement them.

+1 on those.

also following my other comments on T5577 we could use introspection information on those overrides. I doubt C people would be careful to manually define, but for dynamic languages that would allow Efl.Object overrides and would override and expose new methods using efl_object_override, then they could generate automatically (ie: in JavaScript one could hook with Babel and TypeScript to do so, in Python one could use method decorators).

jpeg added a comment.Jun 15 2017, 7:37 PM

What kind of introspection are you talking about?

jpeg added a comment.Jun 15 2017, 7:46 PM
In T5580#89051, @jpeg wrote:

What kind of introspection are you talking about?

Nevermind I think it's just what you are talking about in T5577, but for overrides and not just eolian.

+2

:)

Also we can not layer multiple overrides, i.e. if a function is overriden once, then we can override it a second time but then the first override becomes inaccessible (efl_super can not support that).

you aren't proposing making this possible.. are you? it didn't seem so... so we're accepting this as a normal gotcha and efl_object_override() simply modifies the single layer of overrides (and if it's all NULL then no more layer exists)... right?

jpeg added a comment.Jun 15 2017, 10:13 PM
In T5580#89057, @raster wrote:

Also we can not layer multiple overrides, i.e. if a function is overriden once, then we can override it a second time but then the first override becomes inaccessible (efl_super can not support that).

you aren't proposing making this possible.. are you? it didn't seem so... so we're accepting this as a normal gotcha and efl_object_override() simply modifies the single layer of overrides (and if it's all NULL then no more layer exists)... right?

I am not proposing this. Discussed it with TAsn before and it's just crazy. The current implementation is simple and this limitation is most likely OK as long as EFL does not use overrides itself, and only application developers use them.

jpeg added a comment.Jul 13 2017, 9:56 PM

I have a pending patch in my branch.