Page MenuHomePhabricator

Do not allow static-function polymorphism
Closed, ResolvedPublic

Description

Right now we support static-function polymorphism. However, we probebly should not do that, since C# and probably other cannot support that exotic feature.

static-function polymorphism is that you can override a class function of class A in class B where class B inherits from class A.

Related Objects

bu5hm4n created this task.Fri, Feb 1, 6:35 AM
bu5hm4n moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Mon, Feb 4, 6:04 AM
bu5hm4n renamed this task from Do not allow static polymorphism to Do not allow static-function polymorphism.Wed, Feb 6, 5:41 AM
bu5hm4n updated the task description. (Show Details)

@lauromoura How is that handled in c# ?

you can have in eo:
A.eo :

class A {
   @class bla_a { ... }
}

B.eo :

class B {
   implements {
      A.bla_a;
   }
}

You can call now a_bla_a(A_CLASS); or a_bla_a(B_CLASS) which would be the calling the implementation of A_CLASS or B_CLASS. How is that handled in C# ? Should we allow that ?

Actually, looking twice at this, we add every single class function to the vtable of the class, which is IMO quite a waste. We should not override this, as the only two languages supporting such a feature are actaully javascript and python where you can also edit vtables in the runtime.

My proposal: Lets drop the class functions from there, class functions in .eo files will just produce normal c functions which can be binded, *no* parameters required. (@zmike, @segfaultxavi, @cedric, comments ?)

Given the headaches that mixins have given us, I'd say we avoid exotic features, yes.
API-wise, it's just a matter of Eolian erroring out when it finds a @class method inside an implements section, right?

No, we should also not allow this in eo at all. And change Eolians generation.

Sure sure, I was asking "API-wise", that is, the only change that affects the API :)

APIs, adjusted:

  • efl_class_functions_set class_ops should go away
  • Every class API generated by Eolian will not have the first API
  • Every implementation API will loose the first and second parameter.

@lauromoura How is that handled in c# ?

you can have in eo:
A.eo :

class A {
   @class bla_a { ... }
}

B.eo :

class B {
   implements {
      A.bla_a;
   }
}

You can call now a_bla_a(A_CLASS); or a_bla_a(B_CLASS) which would be the calling the implementation of A_CLASS or B_CLASS. How is that handled in C# ? Should we allow that ?

C#-wise, this is unsupported (actually I think we don't even generate the implement). static functions there are local to the class they are declared in.

@lauromoura I read out of your reply that you also want to see this feature going ?

@lauromoura I read out of your reply that you also want to see this feature going ?

Do you mean simplifying class functions to be plain C functions? Absolutely :)

Nice, will work at the weekend on that :)