He visto varias preguntas de Scala recientemente (por ejemplo, here, here y here) que requieren el uso de proxies, y ha aparecido más de una vez en mi propio trabajo. La biblioteca de Scala tiene varios rasgos de proxy (14, si conté correctamente). clasesProxies/delegados en Scala
Proxy/rasgos generalmente contienen gran cantidad de repetitivo:
class FooProxy(val self: Foo) extends Foo {
// added behavior
def mymethod = ...
// forwarding methods
def method1 = self.method1
def method2(arg: String) = self.method2(arg)
...
}
trait Foo {
def method1: Unit
def method2(arg: String): Unit
}
Mi primer pensamiento fue definir un rasgo Proxy[T]
que podría ser utilizado de la siguiente manera:
class FooProxy(val self: Foo) extends Proxy[Foo] {
// added behavior
def mymethod = ...
}
donde trait Proxy[T] extends T
. Por supuesto, no es posible definir el rasgo Proxy
sin la magia del compilador.
Mi siguiente pensamiento fue buscar un complemento de compilación (esta capacidad claramente no está en el compilador existente, o las fuentes para esos 14 rasgos de proxy serían mucho más pequeñas). Efectivamente, encontré Kevin Wright's AutoProxy plugin. El plugin está diseñado para resolver el problema de proxy cuidadosamente, junto con otros casos de uso (incluyendo mixins dinámicos):
class FooProxy(@proxy val self: Foo) { ... }
Por desgracia, parece que trabajar en él se estancó en noviembre (2009). Entonces, mis preguntas son
- ¿Continúa el trabajo en el complemento AutoProxy?
- ¿Funcionará esto en el compilador?
- ¿Se están considerando otros enfoques?
- Finalmente, ¿apunta esto a una debilidad significativa en Scala? Después de todo, ¿no sería posible definir un rasgo
Proxy
dado macros de estilo lisp?
Los rasgos no pueden tener parámetros. ¿Estás proponiendo que se agreguen? Además, no ha mostrado nada que no pueda solucionarse con la adición de una conversión implícita. ¿La propuesta de crear una conversión implícita es innecesaria? –
"Los rasgos no pueden tener parámetros": error tonto, reparado. –
Las conversiones implícitas resuelven problemas similares, pero no siempre son adecuadas (de lo contrario, ¿por qué los tipos de EPFL incluirían tantos proxies en la biblioteca de Scala?). Por un lado, incurren en más gastos generales que la delegación. En segundo lugar, el uso extensivo de la conversión implícita puede dañar la capacidad de mantenimiento/legibilidad. –