¿Por qué la inyección de código posterior a la compilación es una mejor idea que la inyección de código de precompilación?

Question

Así que todos sabemos que C# no tiene un preprocesador de macro tipo C (y hay un buen hilo sobre por qué here). Pero ahora que AOP está ganando tracción, parece que estamos empezando a hacer cosas con post-procesadores que solíamos hacer con los preprocesadores (ten en cuenta que solo me estoy mojando los pies con PostSharp, así que quizás esté fuera de la base)

Soy un gran admirador de atributos en C#, pero si un preprocesador se excluyó por buenas razones (que, como antiguo usuario de MFC aún lo cuestiono pero acepto), ¿por qué la inyección de código posterior a la compilación es mejor? idea que la inyección de código de precompilación?

Answer 1

Las razones por las que elegí la compilación posterior al diseñar PostSharp hace 5 años son:

1. Idioma agnosticism.
2. MSIL tiene especificaciones más estables en comparación con los lenguajes de alto nivel (que tienen actualizaciones no triviales cada dos años).
3. La mayoría de las veces, MSIL es el nivel de abstracción que necesita cuando se trata de aspectos. No necesita conocer todas las construcciones equivalentes (pensar f 'using' y 'try-finally').
4. Antes de 2008, nadie ha tenido éxito en la producción de un compilador C# decente. Las dificultades encontradas por Mono fueron lo suficientemente impresionantes, incluso si se han puesto al día.
5. Tratar con binarios parecía mucho más rápido que tratar con el código fuente.
6. El manejo de un conjunto binario permite ejecutarlo; el conjunto que se está procesando puede transformarse. No fue escuchado antes de publicar PostSharp Laos.

Dicho esto, las implementaciones de AOP para C/C++ son de hecho una pre-compilador (WeaveC) y las implementaciones en Java son una extensión del compilador (por la sencilla razón de que hay muchas implementaciones de software libre del compilador de Java).

-gael

Answer 2

Si tuviera que hacer la compilación previa, tendría que interpretar los archivos fuente de todos los diferentes idiomas que admite y luego generar el código en ese idioma antes de pasarlo al compilador. Con el postprocesamiento, puede usar la reflexión para examinar los ensamblajes, ya sea que el idioma original sea C#, Visual Basic o lo que sea.

Answer 3

Es simplemente más simple. IL es un heckofalot más fácil de analizar que el código fuente de C#. Y es un lenguaje agnóstico.

Answer 4

Técnicamente, hay una opción de compilación previa para C# integrada en Visual Studio: The Text Template Transformation Toolkit (T4). Esto le permite hacer cosas bastante sorprendentes en un paso previo a la compilación, y es la base de bastantes productos, como algunos ORM, etc.