Page MenuHomePhabricator

Fix class and namespace name collisions
Closed, ResolvedPublic


Currently, some symbols are prefixes for other symbols (like the Efl.Net.Socket interface and the Efl.Net.Socket.Tcp class).
This has no consequences in C, but it causes troubles in languages like C++, C# and Python where we want to treat each part of the symbol name as a separate namespace (Efl, Efl.Net and Efl.Net.Socket, which conflicts with the Efl.Net.Socket interface).
Clever tricks have been tested (like using upper-case and lower-case variants) but all of them look hackish and do not work everywhere. In Python, for example, the class hierarchy is replicated in the filesystem, and we cannot have a file (class) and a folder (namespace) with the same name, even if the case is different, thanks to our best-friend-forever the Windows Operating System.
Therefore, the conflicts will be solved by renaming some of the symbols, and hopefully we will end up with a more sensible class hierarchy.

In summary: EFL has 457 symbols in the EFL namespace (efl_*.eo files), of which 278 have conflicts (61%).

After some discussion with @cedric, @q66, @DaveMDS, @felipealmeida and @segfaultxavi we agreed (more or less) to some general rules for the renames, depending on the conflict type:

Conflict typeExplanationFixExample problemExample fix
Sibling typesSymbols are unrelated and should not be one inside the otherRename the symbol called like the namespaceEfl.Access, Efl.Access.TextEfl.Access.Object, Efl.Access.Text
Inner typeType2 is internal to Type1Remove namespace and rename Type2 to Type1_Type2Efl.Loop, Efl.Loop.ArgumentsEfl.Loop, Efl.Loop_Arguments
Derived classType2 is a class derived from Type1Add _Base to the base class and put it inside the namespaceEfl.Interpolator, Efl.Interpolator.LinearEfl.Interpolator.Interpolator_Base, Efl.Interpolator.Linear
ImplementationType2 is an implementation of Type1 (which is an interface)Add _Iface to the interface name and put it inside the namespaceEfl.Net.Socket, Efl.Net.Socket.FdEfl.Net.Socket.Socket_Iface, Efl.Net.Socket.Fd

The complete list of conflicts and proposed renames can be found in this google spreadsheet (Renames tab).

With the proposed changes, only 163 symbols need to be renamed (36%).

While waiting for feedback regarding the proposed names, I am already working in the renaming (progress can be tracked in the above spreadsheet).

Do you think that the above naming rules should be enforced by Eolian? This task should then rename all non-compliant symbols, even if they are not conflicting right now.

segfaultxavi triaged this task as TODO priority.
segfaultxavi updated the task description. (Show Details)Apr 4 2018, 8:05 AM
bu5hm4n added a subscriber: bu5hm4n.Apr 4 2018, 8:41 AM

My opinion:

A package somehow describes a set of classes that are serving the purpose of the package name

There are a lot of packages that are build arround a interface, so you have the base interface and a few implementations. (Efl.Gfx.Stack

Therefore i would rename things to something like XXXXXXXX.{Base or Object}, the package then is build arround this interface, and there are a few implemetnations of this interface arround in that package, nothing more. Core value here, the interface is in the same package as the implementations, and thus can be browsed and seen in the browser or documentation as one logical unit

Never code the type of anything in its title

I am not a fan of that, you will see that it is a interface when you look at it, no need to code it in the name, it feels just like a waste of name-space.

Lets try to keep namespaces small

The amount of things that are in Efl.Gfx is huge. So for example, lets pack Efl.Gfx.Stack & Efl.Gfx.Size into theire own packages.

I was waiting for the others to comment first, but...

I agree with all you said, bu6hm0n (damn nickname!). I'd rather use .Object for every clashing symbol than repeat the namespace with an added _Iface or _Base.

However, I'll work on the "easy" renames first and leave the disputed ones for later, so people has a chance to argue against these rules.

Also, I'd love to reduce the size of some of the namespaces and organize them in a more hierarchical way, but I am not sure that is in the scope of this project. @cedric?

@segfaultxavi fixing namespaces problem for bindings is the goal of this task, but it was my understanding that @DaveMDS did prefer a more flat hierarchy.

Contrary to @bu5hm4n, I promote a convention to explicitly state in the name whether it is an interface, mixin or abstract, that is:
IText (or: IfaceText, InterfaceText), AbstractWidget, MixinAccess).

A side-note: In the past we used adjectives as a convention to name small number of interfaces (Scrollable, Editable), but we moved away from that quickly, it seems :)

Anyway, I think being verbose in naming has its benefit for better readability and easier review by other developers so we can discover potential design issues.

I am against using Base. It is very ambiguous (what is "base"? a class, an interface or a mixin?). Again, much harder to review.
In general, defaulting to "Base", "Object" or other suffixes hints that there may be a design issue, and although this type of solution may be a quick fix, it weakens readability.

I'm on the same side of @herdsman here: explicit is bettern than implicit!

So my vote go to prefix all ifaces, abstract and mixins. (InterfaceText, AbstractWidget, MixinAccess)
This will make browsing the documentation much more clear and simple.

conr2d added a comment.EditedApr 6 2018, 11:55 PM

I also suffer from this namespace conflicting issue when writing Vala bindings.
I paused that task, but hope to continue it if this problem is resolved.
I like the solution of @herdsman or @DaveMDS, because exposing type like abstract class, interface or mixin in their name can help developers to get some hints without looking up documents every time.
Personally, I prefer short prefix like I in IEnumerable for interface Enumerable, because it will shorten C APIs.

segfaultxavi added a comment.EditedApr 7 2018, 12:46 AM

Being the last one to join this project I have no strong opinion either way.
I just wanted to remark that renaming Efl.Text to Efl.Text.Text_Iface changed the C API from efl_text_get () to efl_text_text_iface_text_get ().
Maybe some clever translation rules beyond the deduplication can be implemented.
Of course, being very strict when naming the classes will help these rules :)

As from IRC:

Why do you want to have the type encoded ? Where does it help you to know the type of a entity while writing code?

For the case of writing a .eo file

It does not help me to know that the returned object from a API is for example a interface or a mixin or a abstract, its just a not needed information there.
Where does it help me to know the type of the entity in the inheritance list, or in the implements section ? It does not. Those are just unneccessary characters.

In case of the c API

We have to either eo_prefix every single interface abstract / mixin with something sane, that does not carry a load of redundant data with it (ex. efl_text_text_iface_text_get). Which also means that we have a different API namespace structure in c than in other languages. Or we are forcing our users to code things like the text example.

In case of a change of the type

Lets say a interface gets changed to a mixin. (while in beta).
So to keep our consistency the class name also needs to be changed to match the new type. This would first mean that we rename every class name to something else. After that you need to adjust every single .eo file to mirror those changes, ( In case of Efl.Text 282 changes accross several .eo files).

Really, i dont see any benefit of the type in the name of a entity, problems in documentations etc. can be fixed there, but please, let us not draw something like this into the language and api.

Can anyone give me a reallife example of where it is usefull to the type of something in the .eo file? Or where this verbosity is not just eating up characters but also gives some usefull information?

Why do you want to have the type encoded ? Where does it help you to know the type of a entity while writing code?

I'm replying only to this first question because I think this is the focal point of this discussion:
having the type of the class in the name does not help while writing code (for all the reasons you already mentioned) but help
new developers to understand and orient himself while LEARNING efl and all the classes that we are going to provide.

You should try to think as a neewbye developer, not as a expert efl developer. Having the type in class name is IMO more explicit, more clear and easier to understand. And giving the fact that our user base is already too low we should do everything we can to help people get in touch with efl, also at the cost (for us) to type more chars on the keyboard.

cedric added a comment.Apr 7 2018, 4:55 PM

What if we decide that in the C, the function name for an iface is actually just the namespace it exist in ? Wouldn't that work ?


Leaking implementation details like iface or mixin is NOT making anything easier to learn. What is easier:
i) You have entities that are just having names so you can guess most of what they are doing, and take theire types/implementation as blackbox ?
ii) You have entities with names + theire implementation details. Now its a difference to the newbie if something is a interface mixin or abstract. So he has to learn what those things do, check the implementation details how they are implemented. NOTHING that should be part of the API :)

And just a few threads from the java world about naming the interfaces with I in the beginning:

Also, from some book: Martin fowler Partterns of enterprise application architecture, chapter 2: 'Hints on types: superflous or even disinformation, clutters the code.'

The only ecosystem where any convention like this is in charge is basically C# where interfaces are 'I' prefixed, and actaully I is way shorter than _Iface...

@cedric it would work for packages where we have a single interface, but not for packages where we have multiple interfaces, which is the cafe in Efl.Gfx.

(TL;DR section below)

A problem

Allow me to recap and gather a bit of perspective, and then make a couple of proposals.

I think an important difference here is languages with namespace support vs. languages without it (as in C++ vs. C).

When namespaces are supported, you are typically more verbose with your names and hierarchies, because there are in-built mechanisms to write less (like the using or namespace C++ keywords). Also, there are less occasions in which you have to write a full type, because you can use the var keyword, for example.

Obviously, in good old plain C you don't have such language facilities and therefore, if you want to write less, you want short type names and short hierarchies.

The problem here is that we are trying to generate APIs for the two languages from the same hierarchy (specified in an EO file), so one of the two languages is not going to be happy.

Some ideas

I would allow two different hierarchies for C and in C++, because, frankly, the convenience of efl_text_set() in C is impossible to beat, but that does not fit any reasonable namespace hierarchy.

We could have completely separated hierarchies in C and C++, or we could have an alias mechanism that allows both hierarchies to be accessible simultaneously (at least in C). Something like efl_text_set() being an alias for efl_text_text_iface_text_set() (which would be the C equivalent of the C++ Efl::Text::Text_Iface::text_set()).

The aliases could be manually generated (with eo_prefix or something more fine-grained), or could be automatic, using a more advanced version of the deduplicator in Eolian.

The rules to generate automatic short APIs could include what @cedric proposed (remove a level if class is called like the namespace), but could include other ones (for properties called like the class, for example).


I don't think we can use the same API for languages that support namespaces and for languages which don't. I propose:

  • To have either separate APIs or an alias mechanism which allows using (at least in C) the full API and a shortened (more convenient) version of it, simultaneously.
  • The short API can be manually generated (in the EO files) or automatic (with some rules in Eolian).

Final words

@DaveMDS Regarding the convenience of the API for new users, I would leave that to the very excellent tutorials that are planned for this year ๐Ÿ˜ƒ

I have now renamed 75% of the conflicting symbols. The remaining ones are the ones which need a decision on this subject (think of efl_text_text_iface_text_set()). You can take a look at the devs/xartigas/renaming branch if you want.

I like that we are discussing this, let's see if we find a solution that suits everybody, or I will start renaming symbols using my own criteria... ๐Ÿ˜ˆ

While I agree with the last comment, I rather we avoid adding more "eolian magic" to the pile.

I suggested a uniform naming convention even though it will make coding in C cumbersome, as the gain in this that the API becomes "what you see is what you get", without the need for behind-the-scenes alteration of names.
That was, of course, when solutions like "Base", "Object" turned up. I found that as the worst option.


Flattening the namepaces should be enough for now, and the more I consider this the more I think it should be more aggressive.
You should apply the same rule for all cases, that is if you have Efl.Foo and Efl.Foo.Bar types, then flatten to Efl.Foo and Efl.Foo_Bar.

It is the API author's decision whether there is a need for a new namespace (e.g. Efl.Net); if one is needed, then the design should accommodate that.

For the Text API, I believe the following should suffice:

  • Get rid of the Efl.Text namespace. Every Efl.Text.XXX type should be Efl.Text_XXX
  • Same for Efl.Ui.Text namespace. Flatten everything to Efl.Ui.Text_XXX.
q66 added a comment.Apr 10 2018, 6:08 AM

I really dislike the two-hierarchies thing. I think it makes everything unnecessarily more complicated, besides, C-only information in eo files should be kept to a minimum only for interfacing into C; most APIs are fine as they are, and where different name for C is necessary, Eolian already provides all needed features.

Furthermore, I second @bu5hm4n's points regarding iface/mixin in names. I think including these in the names as a rule is a bad and unnecessary idea and it doesn't make anything easier to learn, if anything it makes everything only more verbose and clunkier.

I more or less also agree with @herdsman's latest comment. We should iterate over the APIs a few times, flatten where necessary etc. and try and find a good middle ground that will satisfy all cases.

q66 added a comment.Apr 10 2018, 6:13 AM

Additionally, to point out one of @segfaultxavi's points:

When namespaces are supported, you are typically more verbose with your names and hierarchies, because there are in-built mechanisms to write less (like the using or namespace C++ keywords).

I think this is a dangerous line of thought; overnamespacing even in languages with support for them is not always the best idea for the overall design of the project. I think even when there is namespacing supprt, it should be kept to a degree that would also be manageable without namespaces in C, especially in languages such as C++. Doing "using namespace" in C++ is frowned upon for good reasons, as it causes symbol leakage where you don't want it and eventually things become less manageable than they should be; usually you use full namespace when invoking APIs in C++, and the same applies to a lot of other languages, so that should be kept in mind.

Flattening the hierarchy works for me. Additionally, it is really the simplest of all options, since replacing a . with a _ only affects the eo files, not the C.

However, we are losing the "encapsulation" provided by the namespaces (or packages, in Python). I would like to hear from @DaveMDS and @felipealmeida since they are the users of namespaced languages.

@conr2d, is there a way for me to test your Vala bindings? I am already talking with @DaveMDS and @felipealmeida regarding the Python and C++ bindings, but I still don't have a mechanism to check if all these symbol renames are actually solving anything.

OK, I have renamed the clashing symbols in all the efl_*.eo files (and one elm_*.eo file).

The C++ bindings in the devs/felipealmeida/cxx-lower-case branch are not complaining about symbol redeclarations anymore (it still does not build, due to other reasons). Therefore, it looks like the clashing symbols issue is fixed.

I renamed some of the symbols where it made sense, but, in general, the preferred solution has been to flatten the hierarchy (this is, replaced some . with _).

When I created new names, I tried to state what the class does, and have not included the type of the object in the new name. Putting the type in the name has not been done anywhere in the current hierarchy, so if we decide to do that someday, we'll need to change all other symbols too (not just the conflicting ones).

The resulting hierarchy could still be improved, but I think it is now the responsibility of the API authors to review their work and create non-conflicting names if they think the sub-namespaces are really required (The root problem here was that the hierarchy was badly designed).

I have been rebasing devs/xartigas/renaming to master daily, but if we wait too long for this to land the merge will be a nightmare ๐Ÿ˜„

As a side note, while I was working on this, two new clashes were introduced (and fixed). This will continue until Eolian errors out upon detecting a symbol clash. Has this work started, @q66? Is there anything I can do to help?

q66 added a comment.Apr 13 2018, 7:12 AM

It hasn't started yet. I've come to a conclusion that it is not possible to detect name clashes upon generation no matter what changes we make. I think perhaps we could take the middle ground and do checks only in stuff that is parsed at the time, and for global checking we could perhaps have another tool (sort of an Eolian static analyzer). But that's just a thought atm

Well, I've been doing my global checks with a shameful bash script so far, so the independent Eolian Static Analyzer would work for me. It would need to be incorporated into the build system, though, or people will just not use it.

100% of the conflicts were due to objects using namespaces which were actually an object someplace else (Efl.Text & Efl.Text.Style). As long as Eolian can detect that, it will already be a major improvement.

q66 added a comment.Apr 13 2018, 7:28 AM

I was thinking Eolian tests would be a good place to run the "global" check pass. It wouldn't run directly during build, but we generally make sure make check keeps passing.

@q66 I like that idea, esp. since this would also be a good place for checking if the installed eo files are consistent!

Yep! Definitely. I like that.

q66 added a comment.Apr 13 2018, 9:59 AM

yes, I was thinking this could potentially allow an array of extra checks we couldn't do before to happen.

I have been reviewing @segfaultxavi branch and the only problem I can see a few change that will be controversial :

  • efl.ui.layout becoming efl.ui.layout.object
  • efl_text_set becoming efl_text_container_text_set
  • efl.image.load* becoming efl.loadable_image
  • efl.image.animated becoming efl.animated_image
  • efl_gfx becoming efl_gfx_object

Some would be just better with the use of eo_prefix maybe (efl_text_containter or efl_gfx_object for example). Maybe we can automatically remove the object from all the C generated function (That's kind of what we do with efl.object).

Allow me to explain my reasons for these changes, so we all have more background.

  • I made the effort to try to find alternatives to flattening wherever I could. Efl.Ui.Layout.Object and Efl.Gfx.Object are two of the few cases where I thought that the word "Object" fits, because they are "physical" objects (as in something that takes up screen space), not generic OOP objects. If you think this will never get approved, we can just flatten the hierarchy and move on.
  • I know Efl.Text is going to be the most problematic. efl_text_set() is very appealing, but if we flatten, we create a lot of related classes right at the root of the hierarchy (Efl.Text, Efl.Text_Markup, Efl.Text_Style, Efl.Text_Format, ...). Upon inspection of the Efl.Text interface, I see it only provides a text property, so by implementing this interface you are only saying that you are a class which "contains text". Hence the Efl.Text.Container name.
  • Efl.Image.Load does not seem right to me, because "load" is a verb (or a noun) and we are not describing a method, but a class different from Efl.Image. Hence "Loadable". And since adjectives go before the noun, I thought Efl.Loadable_Image was the most correct spelling.
  • Efl.Animated_Image same as above. I can go with Efl.Image_Animated too, but I see no point in it, since this class is unrelated to Efl.Image.

I am not that familiar with eo_prefix, so I don't see how it can help. If it creates a different hierarchy in C and in the bindings, then I think somebody has already said that this is a harmful thing. Same goes for "magically" removing the word "Object" from the C function names.

Why are we going back to "object" and "container" suffixes? I thought the plan was to just flatten the namespaces (as suggested a few replies above).
Did you get any new information that presents a problem with that solution?

Also, regarding interface naming. As I mentioned before, we had moved away from adjective-based naming convention (e.g. "Loadable") to the simple form. I guess folks didn't like the former.

No new information. You suggested that we should just flatten, and I agree that it is the simplest solution, and it will work everywhere. I have implemented that in almost every case.
However, if we apply that unconditionally, we will be losing the opportunity to create a sensible hierarchy, which is handy for languages supporting namespaces. Hence, my effort to preserve a bit of hierarchy where I thought it made sense.

We can stay away from adjectives in class names, but I would also stay away from verbs :)

Regarding images, what about this:

  • Efl.Image_Animation_Controller for animated images.
  • Efl.Image_Load_Controller for loadable images.

@bu5hm4n was also suggesting that Efl.Image.* could be moved to Efl.Canvas.Image_*.

@herdsman Just flattening lead to some silly situation. What is the point of even having namespace if at the end, everything is in Efl. ? :-)

@segfaultxavi I like the idea of moving Efl.Image.* to Efl.Gfx.Image_* actually. Reason is that this class could one day be used by either the vector graphics scenegraph or the 3d graphics one, not just by our current raster graphics scenegraph. And I also do like the Image_Animation_Controller idea. Using Controller as a key word seems nice to me (We might want to do a review of all our current class and make sure that their isn't any other missed Controller).

As for eo_prefix, this is a way to change the beginning of the function generated by eolian in C. For example, src/lib/eo/efl_object.eo which use eo_prefix: efl, and make all efl_object function actually just start with efl.

Good! I will implement these renames.

What about "Object" and "Container"? Doesn't the explanation that these are "physical" objects and not generic OOP objects convince you, @herdsman ?

"Container" should be reserved to when your object manages children objects. Efl.Text's role isn't that. Anyway, Efl.Text should be flattened so there shouldn't be an issue.
I feel so-so regarding the "Object" suffix, because well, everything that you can make an instance of is an object. Differentiating only a subset of the classes as "object" is something I find confusing.

@cedric, at the worst case you still have Efl.* namespace, so that users of other languages can happily use it without having conflicts with other packages. It doesn't justify forcing yourself to write a complex hierarchy.

As a side note I think Efl Efl.Core (net, loop, io etc.), Efl.Ui. and Efl.Canvas should be enough namespaces for now.

I agree with @herdsman about Container. Container has a very specific meaning IMO.

I also agree that Efl.{Core/Ui/Canvas,etc} could be enough, but I understand that Text is a big domain which could make sense to have its own namespace.
But I'm not convinced either way. Also, some text classes should be in Ui, IMO.

OK, since a better solution does not seem to crop up, I removed the "Container" suffix from Efl.Text and flattened the whole hierarchy.


  • Efl.Gfx.Object --> Efl.Gfx.Entity (Does anybody want to use eo_prefix so C methods are still efl_gfx instead of efl_gfx_entity?)
  • Efl.Image --> Efl.Gfx.Image
  • Efl.Loadable_Image --> Efl.Gfx.Image_Load_Controller
  • Efl.Animated_Image --> Efl.Gfx.Image_Animation_Controller

Is this agreeable?

I have done another review and I am fine with all change. The only think I would like is 57b371b130b048d7369ae952da94b817f1b4b28b to be squashed with the relevant previous text related commit as it introduce some noise in the change.

OK, all Efl.Text-related commits have been squashed together to avoid noise (that was in my TODO too).
I also squashed some other commit pairs (Efl.Gfx turned into Efl.Gfx.Object first and into Efl.Gfx.Entity afterwards. Similar thing for Efl.Image.Load -> Efl.Loadable_Image -> Efl.Image_Load_Controller).
I also added fixes for the new code that is being added every day, insisting in creating new name conflicts!

I can now officially say that I know more about git rebase than I ever wanted to ๐Ÿ˜„

Therefore, I think everything is ready for the major shitstorm of the century...

As people may have noticed, I have landed this. I am just thinking that maybe efl.gfx.entity could actually use an eo_prefix: efl_gfx. Opinion ?

@cedric @segfaultxavi

There is a build error as follows.

lib/ecore/efl_loop_message_handler.eo.cs(6,14): error CS0101: The namespace efl' already contains a definition for MESSAGE_Args'

This error is caused by Efl.Loop_Message's message event and Efl.Loop_Message_Handler's message event.

herdsman added a comment.EditedApr 24 2018, 10:41 PM

Thanks for all the hard work. I believe we can fine-tune this in the near future.

I just want to point out that the commit messages do not reflect the changes:
For example, commit 6b5ac687c1a36569af9804f5e545b197d3892040

Efl.Text.Cursor_* (from Efl.Text.Cursor.Cursor_*)
Efl.Text.Font_* (from Efl.Text.Font.*)
Efl.Text.Format_* (from Efl.Text.Format.*)
Efl.Text.Style_* (from Efl.Text.Style.*)
Efl.Ui.Text_* (from Efl.Ui.Text.*)

However, it has become flat now i.e. Efl.Text_Cursor (and not Efl.Text.Cursor)
It's already in, so nothing to do about it.

Also, let's consider flattening Efl.Ui, so we will have Efl.Ui.Layout and Efl.Ui.Layout.Part Efl.Ui.Layout_Part (and avoid Efl.Ui.Layout.Object).

Thanks again :)

@Jaehyun_Cho I think the problem is in the C# bindings generator:

The class MESSAGE_Args is created to contain the args for the events of a class, in the above scenario, both Efl.Loop_Message and Efl.Loop_Message_Handler have an event called message, so both define a class called MESSAGE_Args. The problem is that this class is defined in the parent namespace (i.e. efl) and they conflict.

I think this auxiliary class should either contain the name of the parent class (e.g. EFL_LOOP_MESSAGE_MESSAGE_Args) or be defined as an internal type of the parent class (accessible through Efl.Loop_Message.MESSAGE_Args, for example).

What do you think, @lauromoura ?

@Jaehyun_Cho I think the problem is in the C# bindings generator:

The class MESSAGE_Args is created to contain the args for the events of a class, in the above scenario, both Efl.Loop_Message and Efl.Loop_Message_Handler have an event called message, so both define a class called MESSAGE_Args. The problem is that this class is defined in the parent namespace (i.e. efl) and they conflict.

I think this auxiliary class should either contain the name of the parent class (e.g. EFL_LOOP_MESSAGE_MESSAGE_Args) or be defined as an internal type of the parent class (accessible through Efl.Loop_Message.MESSAGE_Args, for example).

@segfaultxavi @Jaehyun_Cho yeah, it's on the C# generator. I've updated my patches on the event generation refactor (the series finishing with D5998) with this fix. It'll move the argument struture to the <Class>Concrete class. (C# Doesn't allow declaring classes inside interfaces, like efl.Loop_Message).

@Jaehyun_Cho I confirm that using @lauromoura 's branch I can build the C# bindings (although with warnings regarding malformed XML comments)

So, we need to work on events too. They should not clash with method names.

So, we need to work on events too. They should not clash with method names.




So, we need to work on events too. They should not clash with method names.

I do not understand this. Where is the clash between methods and events?
I am building the C# bindings without problems, apparently (haven't tested them), and I see the Efl.Loop class has a Quit() method and a QuitEvt event. This is not OK?

So, we need to work on events too. They should not clash with method names.

I do not understand this. Where is the clash between methods and events?
I am building the C# bindings without problems, apparently (haven't tested them), and I see the Efl.Loop class has a Quit() method and a QuitEvt event. This is not OK?

We are using the Evt suffix for all events exactly to avoid the clashes mentioned above.

I think the idea behind avoiding it would to be able to make all these items (methods, properties, events, etc) into regular top level members of the class, without depending on suffixes and prefixes.

(Well, for properties in C# we had to make explicit Get*/Set* methods due to the multi-valued properties)

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:56 AM
segfaultxavi edited projects, added efl: language bindings; removed Restricted Project.Jun 11 2018, 7:15 AM
segfaultxavi renamed this task from Rationalize class and namespace names to Fix class and namespace name collisions.Sep 19 2018, 1:15 AM
segfaultxavi closed this task as Resolved.
bu5hm4n moved this task from Backlog to Done on the efl: language bindings board.Dec 18 2018, 4:30 AM
bu5hm4n raised the priority of this task from TODO to Normal.