We can avoid the performance problems by creating a boolean if someone is registered in the event. The event won't get called most of the time because most objects have a parent anyway and the event gets called just for objects with C# wrappers.
Apr 23 2019
Apr 15 2019
So we looked into the problems of finalizers and dispose and we found out that using that is not possible. It is possible the GC collects members of a class that we decide later to ressucitate. That surely wouldn't work, because the members would not have the same state when the class is revived.
Apr 9 2019
Remove test that is not working
Apr 8 2019
Do not register Efl.Object again and again
Fix to use += instead of = in ifdef
Apr 7 2019
Mar 22 2019
Mar 18 2019
@segfaultxavi You're right on both questions.
Mar 17 2019
Mar 6 2019
Feb 28 2019
Feb 1 2019
I'd never think that the class vtable contains the object's vtable. I thought the klass vtable would contain only the vtable for Efl_Class and Efl_Object methods.
Jan 31 2019
Going to add _append, _prepend (for cases without an anchoring child, so beggining and end) and _insert_at for index. Going to do that after I come back to Brazil next week.
Jan 27 2019
I've updated examples.git with new syntax from this diff.
Jan 25 2019
Jan 24 2019
Jan 21 2019
inlists should allow any value-type, not just structs.
Jan 18 2019
Jan 17 2019
This seems to be more than just an API to get the requires?
D7675 is the other commit now
Updating to have just one single commit
I've tried but didn't work for me.
This is what happens when you arc diff multiple commits :-(
OK, then a way to extract that information from Eolian would be necessary.
Maybe, or Eo could enforce this too.
In eolian, but it is not in Eo, so the C# class will not be enforced by this.
@bu5hm4n I think he is mentioning that if a C# programmer implements a mixin, then the regular class will not appear in its class's hierarchy. However, the user should inherit from the regular class (or some derived class) since the mixin requires it.
Shouldn't the user that will be inheriting from the mixin also inherit from the same regular class? It is not tested, but we could add a runtime test. This needs documentation, however.
Jan 16 2019
Jan 15 2019
Please review branch devs/felipealmeida/interface_inherit
Jan 14 2019
C# binding is not suppose to be doing that. It, AFAIR, just ignores regular classes in mixins.
fixing what I screwed up
oh my god!
well, somehow everything got included
Jan 13 2019
@lauromoura is going to test this hypothesis in his branch
The only thing missing is the optional parameters.
I think we can use Nullable<T> for non-object types and for object types the only options are always going to be null for default values, or no default-value. So we can fix null as being a default and that's it. I don't think we need default-values.
Added description in commit
I like the way it is.