Concrete classes serve as a wrapper for eventual private classes that implement the given interface, akin to the *Realized classes for abstracts.

In D8582#161167, @segfaultxavi wrote:

I think this can be solved very easily by making C# suffix parts with Part automatically, just like events. Then we can remove the restriction that parts cannot be named like other properties (just like events).

Let me explain:

We have different kinds of symbols in EO files: Namespaces, Classes, Methods (and Properties), Events and Parts.
In C they can have the same name, symbol clashes are not a problem, and this is why originally our hierarchy had lots of duplicates.

When we started implementing bindings, some languages had issues with the symbol clashes: Python and C# cannot have a class named like a namespace (not even changing the case, because in Python class hierarchy maps to the filesystem, and the Windows filesystem is case-insensitive). In C# a property cannot have the same name as the class, etc.
We started solving these issues in different ways, and I think this was a mistake. For example, in C#, events are automatically suffixed with Evt so clashing is resolved, but not so parts.

As a result, these are the current rules that eolian is enforcing (as far as I understand):

• Classes cannot clash with Namespaces
• Methods (and Properties) cannot clash with anything
• Events cannot clash with other events
• Parts cannot clash with anything
  
  I think these rules work nicely for all cases except parts, which we have not used much yet. So, if the C# bindings suffix parts with Part just like events are suffixed Evt we can remove the restriction on part names and we can use more sensible names like text, icon and extra (without prefix). Of course, names will still need to be unique inside a widget's hierarchy (a part cannot have the same name as another part up in the hierarchy).
  
  What do you think @cedric, @SanghyeonLee, @lauromoura, @q66 ?

This is just a struct to wrap the event parameters. The event documentation itself is already present in the EventHandler field.

Update after Xavi's comments

I had added this fix in D8811 alongside others. Added you as reviewer there.

Update fixing typo.

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Update with test and extra fix

Results of expedite-cmp (I've patched it to aggregate the average values of the comparison files in the second column):

I caught this error after doing a fresh install without old modules installed.

E compiles correctly after this.

Removed uneeded initializations

The failure occurred because the Dummy.TestObject.set_value implementation either freed the stored value or created the new one. This worked normally outside of debug mode probably due to mempool reusing the memory address. The debug build uses the pass-through mempool, making the problem appear.

Rebase and fix comment.

Here I get a segfault when trying to create an empty Eina_Value (before assigning). And looks like there is more instability regarding Eina (at least with C# apps). Some calls to Eina.Log.Error also made the program crash. Will investigate more.

After D8550, Concrete classes constructors are private and regular classes intptrs constructors are protected.

Abandoning as this will be split in future diffs.

I have a working patch here moving the NativeInherit classes into a nested NativeMethods class. I'll do some more tests whether these SuppressMessage directives are necessary.

Update moving check for empty string to root generate_tag.

In D8612#156561, @segfaultxavi wrote:

Much nicer, but there is still some non-perfect whitespace:
If you search for ///< (without separating space) in klass.h and struct_definition.hh you can find many places.

This probably will depend on T7800.

Update after vitor comments

Another task that we should take into account together with this is T7785, when C-land uses efl_add/add_ref/new to create instances of C#-derived classes (like in widget factories).

Remove uneeded Console.WriteLine

The stack below fixes this instance of the FindProvider problem by making sure only C#-overriden methods are called from C. The proper way to handle private classes will be dealt with in T7789 and related tasks.