No se puede acceder a los miembros de los padres cuando se trata de macro anotaciones

Estoy bloqueado con la siguiente situación ( macro anotación ). Supongamos que tengo una anotación llamada @factory que pretende generar un método de apply para el rasgo anotado en el objeto complementario correspondiente. Por ejemplo, dado el trait A :

 @factory trait A { val a1: Int } 

el código esperado para generar es el siguiente:

 object A extends Factory[A] { def apply(_a1: Int) = new A { val a1 = _a1 } } 

Ahora supongamos que tenemos un rasgo B que hereda de A :

 @factory trait B extends A { val b1: String } 

que se supone que genera:

 object B extends Factory[B] { def apply(_a1: Int, _b1: String) = new B { val a1 = _a1 val b1 = _b1 } } 

En este último caso, necesito saber cuáles son los atributos que existen en A , pero no sé cómo obtener información sobre ellos . Al tratar con anotaciones macro, solo tengo acceso a B rasgo AST (como un ClassDef ). Aunque su template contiene referencias a los padres (como TypeTrees ), ambos campos, tpe y symbol están vacíos.

Sería genial para mí tener acceso a la A AST. Sin embargo, creo que eso no es factible. Por lo tanto, cualquier símbolo o tipo (señalando el padre o el tipo actual) sería lo suficientemente bueno.

Si desea ver más detalles de implementación, he cargado el proyecto a https://github.com/jesuslopez-gonzalez/cool-factory . Puede generar la apply para los valores locales.

Los árboles que entran en los argumentos de macroanotación están desactualizados a propósito. Sin embargo, ejecutar c.typeCheck(q"(??? : )").tpe proporcionará la información que falta. No te olvides de duplicate ese árbol antes de la verificación de tipos, ya que c.typeCheck muta el árbol en su lugar, lo que podría no ser deseable.

En caso de que tanto el padre como el hijo se declaren en el mismo scope no a nivel, habrá un problema de que typeCheck no vea el padre, ya que las anotaciones de c.typeCheck se realizan en el ámbito léxico principal, de modo que las anotaciones no se obtienen para ver scopes a medio construir. Algo similar ha sido reportado aquí: https://github.com/aztek/scala-workflow/issues/2#issuecomment-23947943 .

La decisión de excluir el scope actual de la verificación de tipo no es definitiva. Esta semana voy a pensar un poco más acerca de cómo las macroanotaciones deberían interactuar con los ámbitos de inclusión, y probablemente lo cambie para hacer lo que le gustaría que hiciera. Haría el cambio ahora mismo, pero necesito asegurarme de que no haya ningún comportamiento loco como resultado de ese cambio.

    Intereting Posts