¿Por qué los filtros de fuente Perl son malos y cuándo está bien usarlos?

source-filter

Question

Es de conocimiento común que los filtros fuente son malos y no deben usarse en el código de producción.

Al responder a una pregunta similar, pero más específica, no pude encontrar ninguna buena referencia que explique claramente por qué los filtros son malos y cuándo pueden usarse con seguridad. Creo que ahora es el momento de crear uno.

1. ¿Por qué son malos los filtros de origen?
2. ¿Cuándo está bien usar un filtro de fuente?

Answer 1

Aquí hay un buen ejemplo que muestra los problemas que puede encontrar con los filtros de origen. http://shadow.cat/blog/matt-s-trout/show-us-the-whole-code/

Utilizaron un módulo llamado Switch , que se basa en filtros de origen. Y debido a eso, no pudieron encontrar el origen de un mensaje de error por días.

Answer 2

El problema que veo es el mismo problema que se encuentra con cualquier macro de C / C ++ más compleja que la definición de una constante: degrada su capacidad para comprender lo que hace el código mirándolo, porque no está mirando el código que en realidad ejecuta

Answer 3

En teoría, un filtro fuente no es más peligroso que cualquier otro módulo, ya que puede escribir fácilmente un módulo que redefine construcciones internas u otras construcciones de forma "inesperada". En la práctica, sin embargo, es bastante difícil escribir un filtro de origen de una manera en la que pueda demostrar que no va a cometer un error. Intenté escribir un filtro fuente que implemente los operadores de alimentación perl6 en Perl6::Feeds ( Perl6::Feeds en cpan). Puedes echar un vistazo a las expresiones regulares para ver las acrobacias necesarias para simplemente descifrar los límites del alcance de la expresión. Si bien el filtro funciona y proporciona un banco de pruebas para experimentar con los alimentos, no consideraría usarlo en un entorno de producción sin muchas horas de prueba.

Filter :: Simple ciertamente es útil al tratar con ''los detalles sangrientos de las construcciones analizadas'', así que sería cauteloso con cualquier filtro fuente que no empiece allí.

En total, realmente depende del filtro que está utilizando y de cuán amplio es el alcance con el que intenta hacer coincidir. Si es algo simple como ac macro, entonces su "probablemente" está bien, pero si es algo complicado, entonces es una decisión. Personalmente, no puedo esperar para jugar con el sistema macro de perl6. Finalmente lisp no tendrá nada en perl :-)

Answer 4

No me gustan los filtros de origen porque no se puede decir qué código va a hacer simplemente leyéndolo. Además, las cosas que parecen no ser ejecutables, como los comentarios, podrían ser mágicamente ejecutables con el filtro. Usted (o más probablemente sus compañeros de trabajo) podría eliminar lo que usted piensa que no es importante y romper las cosas.

Una vez dicho esto, si está implementando su propio pequeño lenguaje que desea convertir en Perl, los filtros de origen podrían ser la herramienta adecuada. Sin embargo, simplemente no lo llames Perl. :)

Answer 5

Por qué los filtros de fuente son malos:

1. Nada más que Perl puede analizar Perl. (Los filtros de origen son frágiles)
2. Cuando un filtro fuente se rompe, casi todo puede pasar. (Pueden presentar errores sutiles y muy difíciles de encontrar).
3. Los filtros de origen pueden romper las herramientas que funcionan con el código fuente. (PPI, refactorización, análisis estático, etc.)
4. Los filtros de origen son mutuamente excluyentes. (No puedes usar más de uno a la vez, a menos que seas psicótico).

Cuando están bien:

1. Estás experimentando.
2. Estás escribiendo código desechable.
3. Tu nombre es Damian y debes poder programar en latín.
4. Estás programando en Perl 6.

Answer 6

Vale la pena mencionar que las palabras clave Devel::Declare (y que comienzan con Perl 5.11.2, palabras clave conectables) no son filtros fuente, y no entran en conflicto con el problema "solo perl puede analizar Perl". Esto se debe a que son ejecutados por el analizador de perl en sí, toman lo que necesitan de la entrada y luego devuelven el control al mismo analizador.

Por ejemplo, cuando declaras un método en MooseX::Declare así:

method frob ($bubble, $bobble does coerce) {
  ... # complicated code
}

La palabra "método" invoca el método parser de palabras clave, que usa su propia gramática para obtener el nombre del método y analizar la firma del método (que no es Perl, pero no necesita serlo, solo debe serlo). definido). Luego deja perl para analizar el cuerpo del método como el cuerpo de un sub. Cualquier cosa en cualquier lugar de su código que no esté entre la palabra "método" y el final de la firma de un método no se ve en absoluto por el analizador del método, por lo que no puede romper su código, sin importar qué tan complicado sea.

Answer 7

Solo perl puede analizar Perl (vea este ejemplo ):

@result = (dothis $foo, $bar);

# Which of the following is it equivalent to?
@result = (dothis($foo), $bar);
@result = dothis($foo, $bar);

Este tipo de ambigüedad hace que sea muy difícil escribir filtros fuente que siempre tengan éxito y hagan lo correcto. Cuando las cosas van mal, la depuración es incómoda.

Después de estrellarme y quemarme varias veces, he desarrollado el enfoque supersticioso de nunca intentar escribir otro filtro fuente.

Sin embargo, de vez en cuando uso Smart::Comments para la depuración. Cuando lo hago, cargo el módulo en la línea de comando:

$ perl -MSmart::Comments test.pl

para evitar cualquier posibilidad de que permanezca habilitado en el código de producción.

Ver también: Perl no puede ser analizado: una prueba formal