Cita:
Iniciado por lolainas 
No había visto eso...
La primera solución es igual a la que propuse más arriba , con el añadido del chequeo de clases, y la complicación de no usar __call, pero funciona.
Sin embargo, si se quiere hacer una solución "completa" (ya que está marcado como "aporte"), debería gestionar clases derivadas.No es suficiente con llamar a get_class para hacer matching de clases.Si B extiende de A , un metodo que está declarado como que recibe un parametro de tipo A , debería poder recibir un parametro de tipo B (uso de get_parent_class tantas veces como sea necesario).
Gestionar namespaces también sería un bonito añadido.Y métodos estáticos.
La segunda solución, usando Reflection, es innecesariamente complicada (una clase abstracta sin métodos abstractos??), y no funciona.Utilizar los nombres de parámetros como discriminador, significa que no puedes declarar una función que reciba 2 parametros del mismo tipo ($array,$array).
Utilizar Reflection sólo sería necesario para una cosa: permitir parámetros con valores por defecto.Una funcion con signature a_integer_integer_integer($a,$b,$c=null), podria ser invocada
aunque sólo se llamara con a(1,1).
La tercera solución, aún más complicada, vuelve a no funcionar por el mismo motivo anterior, aparte de que hacer varias expresiones regulares en __call..Al menos, eso debería cachearse en el constructor, y no chequearlo en cada llamada.
Todas las soluciones utilizan innecesariamente el numero de argumentos como parte del nombre del método, cuando la coincidencia del numero de argumentos está implícito en el chequeo de tipos.
Es un post interesante, porque muestra el peligro de hacer sobre-ingeniería de las cosas.La primera solución era simple y básicamente correcta, sólo faltaba el conveniente detalle de __call y el retorno de valores.El resto de cosas a añadir para una solución completa, se podría hacer de forma igualmente simple.