Page MenuHomePhabricator

Fix consistency of the Interfaces Hierarchy
Open, TODOPublic


When the previous big rename was done (T6847) the goal was to fix the object/namespace collisions so work on bindings could continue.
We knew then that the hierarchy after the rename was inconsistent and would need to be fixed later on.

It has been brought to my attention (D7013#122400) that this work is still pending.

Basically, in some places we used a namespace, as in Efl.Canvas.Vg.*, and in some other places we haven't, as in Efl.Canvas.Animation_* (note the dot and underscore notation). Sometimes the "main" class in a namespace has been called Object, but sometimes that name was already taken.

We should homogenize the whole hierarchy to make it easier to use.

This is the current list of conflicting classes and their proposed new name. This list will be updated as the discussion in this ticket proceeds.

Current nameProposed new nameComments
EflIoFilterEio.Filter_CbThere's a bit of namespace mixup here, @cedric ?
Efl.*_InterpolatorEfl.Gfx.*_InterpolatorSee comment T7408#127431 below
segfaultxavi triaged this task as TODO priority.

We need to decide which name is categorized as a namespace and which is not.

As we discussed for elementary widgets, we concluded we do not use namespace under elementary widget.
(i.e. Efl.Ui.Layout and Efl.Ui.Layout_Part instead of Efl.Ui.Layout.Object and Efl.Ui.Layout.Part)

However, other names have not decided yet.

Maybe continuing this is just fine?

Having the namespace Efl.Gfx and Efl.Canvas (etc.) for the classes in there, but no deeper namespaces ?

A few other namespaces need consideration if they are fine like this, like efl_text (feels to me that this could go into Efl.Gfx ?)

To move forward we need the full list of names which are confusing, and then we can think about alternatives.
@Jaehyun_Cho, since you seem to be pushing this effort, do you mind preparing this list and writing it in this ticket?

This comment was removed by Jaehyun_Cho.


If we only talk about namespaces under "Efl.", then it would be as follows.
(I only write namespaces except class, abstract, interface, mixin name itself)

  • Efl.Layout : edje
  • Efl.Canvas : canvas(evas)
    • Efl.Canvas.Vg : canvas vector
    • Efl.Canvas.Filter
  • Efl.Io : input/output
  • Efl.Net : ecore_con
    • Efl.Net.Constrol
    • Efl.Net.Ssl
  • Efl.Ui : widget(elementary)
    • Efl.Ui.Focus : elementary focus
    • Efl.Ui.Scroll
  • Efl.Page
  • Efl.Access : accessibility
  • Efl.Gfx : graphics
  • Efl.Input

I think that some of the above should be removed and some of new namespaces should be added.
To add or remove namespaces correctly. I believe we need to investigate other UI frameworks.

So now I am investigating class hierarchies and namespaces in the Android.
Although Android's namespace is different from our eo class namespace, but I think it would be one of the great examples we can refer.
If I gain some insight how to improve or organize our eo class namespace, then I will share with you. :)

@Jaehyun_Cho lets copy this list into the task description and add remove things to it ?

I just found Efl.*.Interpolator, which probebly needs to be renamed to something like Efl.Gfx.Interpolator.* ?

@Jaehyun_Cho Thanks for the list of namespaces. I think it would also be helpful if you added to the list the classes which use a namespace as part of the name (like Efl.Canvas.Animation_* or Efl.Canvas.Object). In this way, we can easily see where are the conflicts and can start thinking about alternate names.

Maybe this page can be useful for this task (the "Namespaces hierarchy" link)

its the full namespace map, it has been generated something like 15 days ago

I just realized there's another inconsistency. Function callbacks (labeled function in EO) are also inconsistently named:

$ find src/lib -regex ".*\.eot?" | xargs grep -e "^function"
src/lib/elementary/efl_ui_dnd_types.eot:function Efl.Dnd.Drag_Icon_Create {
src/lib/elementary/efl_ui_dnd_types.eot:function Efl.Dnd.Drag_Data_Get {
src/lib/elementary/efl_ui_dnd_types.eot:function Efl.Dnd.Item_Get {
src/lib/elementary/efl_ui_dnd_types.eot:function Efl.Dnd.Drag_Icon_List_Create {
src/lib/elementary/efl_ui_widget.eo:function Efl.Ui.Scrollable_On_Show_Region {
src/lib/elementary/efl_selection_types.eot:function Efl.Selection_Data_Ready {
src/lib/efl/interfaces/efl_ui_format.eo:function Efl.Ui.Format_Func_Cb {
src/lib/ecore/efl_threadio.eo:function EFlThreadIOCall {
src/lib/ecore/efl_threadio.eo:function EFlThreadIOCallSync {
src/lib/ecore/efl_loop_consumer.eo:function EflLoopConsumerPromiseCancel {
src/lib/eio/eio_model.eo:function EflIoFilter {
src/lib/eio/efl_io_manager.eo:function EflIoPath {
src/lib/eio/efl_io_manager.eo:function EflIoDirectInfo {

I think the correct approach is the one followed in Elementary and we need to rename the functions in Ecore and Eio.

@segfaultxavi it seems we can now add the namespace in the function name. I indeed prefer that too. Next question is should we postfix the function with : Func_Cb, Cb, whatever ? or nothing ? I think I would lean toward postfixing with _Cb. What do you think ?

I also lean towards _Cb. It is nice to have an indication that this is a callback, but _Func_Cb seems too long.

I added the list of proposed changes to the task description. Please keep commenting to make the list grow!

I just found Efl.*.Interpolator, which probebly needs to be renamed to something like Efl.Gfx.Interpolator.* ?

All interpolators inherit from the Efl.Interpolator interface. If we want to turn Efl.Interpolator into a namespace, we need a name for the base interface. This situation happens in a lot of places and was already studied in the previous rename, resulting in the current names.
I do agree that Efl.Gfx is a better location, but I wouldn't turn Efl.Interpolator into a namespace unless we can find a good generic word to describe base interfaces spawning all other interfaces in a namespace.

segfaultxavi updated the task description. (Show Details)Dec 24 2018, 2:31 AM
zmike added a comment.Jan 2 2019, 10:44 AM

_Cb has been the standard in EFL since just prior to the 1.0 release, so continuing to use this would maintain consistency.

I wonder, however, if we really want to keep mixing CamelCase + underscore in things which could propagate to bindings? This applies to a number of classes and types, so it's probably worth discussing?

Our .eo files use CamelCase + underscore in general (I think it is the rules that bindings expect). Binding can then use that as an easy hint to do what they want, as long as our rules is properly enforced in all our .eo. I think it makes sense to use CamelCase + underscore + postfixed _Cb for all function callback naming so that binding don't have to do anything special there.

zmike added a comment.Jan 2 2019, 11:05 AM

Oh okay. I guess I was thinking for "EFL 2.0" in the C API; capitalization + underscores is pretty painful, so it might be nice to consider a change there.

CamelCase+Underscores looks weird to me too, but that seems to be the EO convention. It is turned into lowercase+underscore in C and plain CamelCase in C#, so I am not very worried about this.

@Jaehyun_Cho, you provided a list of conflicting namespaces, but it would be nice to have the list of conflicting classes, so I can added them to the task description and then we think about new names. Can you provide the list of classes?

segfaultxavi updated the task description. (Show Details)Oct 4 2019, 3:38 AM

Maybe it's time we took a look at this task again.

At the very least, we should unify the convention for callbacks, _Cb or not?

Also, there was talk about putting Interpolator classes inside Gfx. What do you think?