Flujo de control COMEFROM

Question

De acuerdo con wikipedia El control de flujo COMEFROM se considera una broma, ilegible o francamente nocivo. Me imagino que tal característica sería muy útil en los escenarios de AOP (es decir, agregar el registrador a los métodos sin agregar llamadas de registrador a los métodos).

¿La desventaja de la no evidencia de una estructura de control de este tipo es mayor que la utilidad potencial? ¿Hay alguna otra desventaja a considerar?

Preguntado por esta pregunta debido a this.

Answer 1

Para empezar es básicamente inútil en cualquier lengua moderna porque es necesario para cualquiera:

• la posición de referencia para saltar de por número de línea, y estos son volátiles.
• Coloque un marcador o etiqueta en el código para denotar una posición que se puede saltar, destruyendo así los posibles beneficios de no tener que hacer esto.

también:

• hace que cualquier tipo de depuración mediante inspección esencialmente inútil.
• Realmente no se puede capturar ningún contexto desde donde saltó, a menos que se mantengan las variables persistentes, lo que es un problema.

Una mejor idea sería su lugar:

• Escribe un API de enganche.
• ¡Llame a una función!

Answer 2

Para el propósito que menciona, Aspect Oriented Programming (wikipedia) parece una solución más organizada que comefrom. Consulte la parte inferior de Motiviation and Basic Concepts (ibid) para ver un ejemplo de cómo se puede agregar el registro a un método en una unidad de texto separada.

En un lenguaje suficientemente dinámico, es posible para manejar este tipo de cosas el uso de "wrap-around" modificadores a un método:

def do_something 
    ... 
    end 
    log :do_something, "Something got done" 

En este ejemplo artificial, la log macro hace que el método do_something a ser reemplazado por un nuevo método que primero llama al método original do_something, y luego escribe algo en el registro.