Talking today about some examples using the new API we came up with the
following situation:
```
Eo *_screen = efl_add(EFL_UI_TEXT_CLASS, ...);
...
Efl_Text_Cursor_Cursor *cursor = efl_text_cursor_get(_screen,
EFL_TEXT_CURSOR_GET_TYPE_MAIN);
```
The call seems to succeed in C but it is a compilation error in C#, as
`Efl.Text_Cursor` is not in the inheritance/interface tree of `Efl.Ui.Text`.
What seems to be happening is:
* `Efl.Ui.Text` composites with `Efl.Text_Interactive` and `Efl.Text_Markup`
* `Efl.Ui.Text` internally uses `Efl.Ui.Internal.Text.Interactive` as a
composite
* `Efl.Ui.Internal.Text.Interactive` implements `Efl.Text_Interactive`.
* This satisfies `composite_attach` requirement and will forward the
`efl_text_interactive` calls to the composite object.
* `Efl.Ui.Internal.Text.Interactive` *also extends* `Efl.Text_Cursor`
through `Efl.Canvas.Text`
Given this, C code seems them to be able to call `Efl.Text_Cursor` methods
on the `Efl.Ui.Text` instance through its composite, even though
`Efl.Ui.Text` has no idea `Efl.Text_Cursor` exists.
This may work in C (but should it?) as we just pass `Eo*` around and do the
actual checks at runtime, but for strongly typed languages like C# this
means the generator has no way to know text cursor methods would be
available through composition and trying a similar code would lead to
compilation errors.
Shouldn't Eo somehow (debug build if too expensive?) intercept these calls
and emit a warning to avoid such usage?
(For this particular case, a fix could be making `Efl.Ui.Text` declare
`Efl.Text_Cursor` as a composite, right?)
--
Lauro Moura
Expertise Solutions
"lauromoura" on FreeNode
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
