Page MenuHomePhabricator

EFL API considerations
Open, TODOPublic

Description

There are a lot of components in EFL. The #interfaces project is an attempt to provide a more coherent API based on these components.

If the objective is to provide more coherency, why are the components "under" the interfaces being excluded? For example, there are eina types which are returned/used in .eo files, and they are still using the eina namespace? It seems to me that, at a minimum, those types should be moved into the efl_ namespace to avoid confusion. There is also the potential to do some cleanups if such a move/rename were to occur.

zmike created this task.Jun 14 2018, 6:06 AM
zmike triaged this task as TODO priority.

I seem to remember Cedric telling me that Eina was to be kept out of the EFL namespace, since it is a standalone library and its separation from EFL is clear.

Is this not the case? What is the gain in merging Eina into EFL?

zmike added a comment.Jun 14 2018, 8:25 AM

I don't know what the plan was for this or if there was one since there does not seem to be any record of such a plan that I could find.

The main points here would be:

  • does it make sense to discard and/or make private any of the non-interfaces public API?
    • ecore-evas, ecore-*, eina, eet, efreet, ...
  • does it make sense that we (EFL) ship a library (EINA) which is utilized by our public, "unified" API but is not part of that API?
    • will "new" developers be confused why e.g., efl_object_debug_name_override takes an Eina_Strbuf type and not Efl_Strbuf ?

While I can understand that these APIs are not using eo/lian, it does seem potentially confusing to have all these other random libraries and namespaces still be in existence after a so-called cleanup of the API.

  • does it make sense to discard and/or make private any of the non-interfaces public API?

Sorry, are you asking "why are we doing this" or "should we be doing this"?
(If my lack of background is a hindrance for the discussion just tell me and I will stop interfering).

  • does it make sense that we (EFL) ship a library (EINA) which is utilized by our public, "unified" API but is not part of that API?

If the cut is clean, I see no problem. Eina takes care of basic types and Efl all the rest. Just like GStreamer and GLib: you've got g_ functions and gst_ functions, and sometimes it gets messy when you have G_DEBUG and GST_DEBUG (And I know Eina is not as widespread as GLib).
Regarding the documentation, I do not foresee any problem to explain this separation.

Moreover, having a separate type library allows for other programs to use it independently of EFL (like eolian_gen), and it looks a bit more professional, since it does not seem like we only use in-house tools (this is highly subjective, agreed).

All this is very arguable, for sure.

zmike added a comment.Jun 14 2018, 8:58 AM
  • does it make sense to discard and/or make private any of the non-interfaces public API?

Sorry, are you asking "why are we doing this" or "should we be doing this"?
(If my lack of background is a hindrance for the discussion just tell me and I will stop interfering).

The latter. I think we should clearly establish which APIs will be public/private/removed for 2.0 long before the release process for 2.0, as this may affect the direction of development for existing components.

My background is roughly similar to yours; I'm not sure there is anyone left who really knows the full scope of what was supposed to be done.

  • does it make sense that we (EFL) ship a library (EINA) which is utilized by our public, "unified" API but is not part of that API?

If the cut is clean, I see no problem. Eina takes care of basic types and Efl all the rest. Just like GStreamer and GLib: you've got g_ functions and gst_ functions, and sometimes it gets messy when you have G_DEBUG and GST_DEBUG (And I know Eina is not as widespread as GLib).
Regarding the documentation, I do not foresee any problem to explain this separation.

The major difference in this case is that eina is more or less just data types, whereas glib includes the main loop implementation.

Moreover, having a separate type library allows for other programs to use it independently of EFL (like eolian_gen), and it looks a bit more professional, since it does not seem like we only use in-house tools (this is highly subjective, agreed).

All this is very arguable, for sure.

If you, as a newcomer, think that it's reasonable then perhaps it is. We may want to try seeking more opinions on the matter from non-EFL developers.

I believe Eina should be in the EFL namespace, simply because it is part of the EFL... Look at the history of the EFL... All libraries were EFL, every library that we developed and provided. While yes, Eina may be the lowest level and doesn't use any other part of the EFL and is simply there to be used, it is still part of the EFL and not namespacing it as such is confusing and implies otherwise. Further moving the lower level libs like eina, ecore, eio, etc... into a common namespace could help eliminate potential duplication that exists between those libs, such as file functions (eina, ecore, and eio all have file functionality, ecore and eio have file monitors), Thread functions (eina and ecore both have thread functionality), and other areas of potential duplication.

raster added a subscriber: raster.Jun 17 2018, 7:51 PM

i don't believe that eina is a "separate library". like @stephenmhouston says. it's as much integrated into efl as just about everything else... it's a root dependency and can/t even be compiled just on its own.

i think it was because of namespace clashes. efl_ui_list vs. eina_list->efl_list - or well there being a lot of potential for clashes if we did eina -> efl.

if we were to change namespace for eina, i think we need to go have a good look at the api design choices in it as part of it. especially lists. like:

list = eina_list_append(list, x);

this was a copy of the design from glib, but over the years i've come to realize .. it's a bad design. i'd also go for hiding data structures much more. lists are exposed and thus we can't alter the list node struct at all. we can extend it... but not otherwise alter. this means basically no optimizations possible. my take is a list should be more opaque like:

efl_list_append(&list, x);

this way the list ptr can be NULL when empty, and otherwise allocated on demand (and deallocated when list is empty) etc. ... the internals of the list are also hidden which means it can even silently re-organize layout internally to be more optimal given the runtime uses of that list.

eina_hash isn't bad in this way - but i'd try and make its design as similar as possible like the above (pass ptr to hash handle, so efl_hash_add(&hash, x) or similar).

my point here is ... a "blind rename" (sed s/eina_/efl_/g etc.) is probably a bad idea. The right thing here is to carefully go over what is in eina an rename where appropriate, redesign for improvements, and simply don't covert over what probably should not be in our future api like api's that are not tested or used regularly: eina_safeptr, eina_lalloc maybe and some others? keep them in eina but don't have "new efl namespace" for them until there is a really good reason to.

the downside of the above is... this is a long and slow path, not a fast one. no "just use sed" :)

cedric added a subscriber: cedric.Dec 21 2018, 9:50 AM

The reason why eina is not part of efl namespace is because what is in the efl namespace is supposed to be shared among all bindings. In most language what is in eina is already available in that said language. So it is expected that in most language you would not see the eina type, but directly the native language type. This is why we are removing reference to eina type from the .eo file. Ideally there shouldn't be any Eina data type directly exposed in .eo files so that they will more transparently refer to the binded native language type.

Basically, Eina is C only and as such it is only relevant for C and is independent from the rest of the Efl namespace which is expected to be available to all language.