PHP 5.3 incluye soporte para “goto”

10/06/2009

Y yo me pregunto: ¿Para que diablos?

No es que me cierre a que las instrucciones goto sean malignas por si solas como aprendes en la escuela. Seguro que han de tener su buena utilidad. Solo que esta la veo en lenguajes estructurados o que no tienen soporte para excepciones, y PHP no cae en ninguno de esos casos.

También podría aplicar la técnica “sino te gusta, no lo uses”. Pero el problema no es así de sencillo, ya me veo en el futuro debuggeando las pastas ininteligibles de HTML+Javascript+PHP que existen, pero ahora “mejoradas” con goto. The horror!

Vía: Reddit

«Anterior | Siguiente»

Hay 9 comentarios:

11/06/2009Moises Silva dice:

Pos, yo no llamaría a PHP un lenguaje orientado a objetos. Que te permita programar con algo de orientación a objetos es otro asunto, pero de la misma forma puedes querer programar estructurado y el goto es invaluable para manejar condiciones de error facilmente y evitar inmensos if, else.
11/06/2009Oscar dice:

Yeah!, esto es exactamente lo que necesitamos en php, características que agreguen más complejidad a la estructura y faciliten aún más la programación floja y con malas prácticas.

Oh esperen no, es todo lo contrario…
11/06/2009levhita dice:

Un link, sólo un link: http://phparch.com/c/news/view/8
11/06/2009pecesama dice:

Concuerdo completamente contigo y con Oscar, lo ‘evil’ de estas cosas son las malas prácticas. Con respecto a lo que dice Moises me suena más al viejo PHP4 que a lo que se puede hacer desde PHP5, que por supuesto si alguien quiere no programar orientado a objetos eso es otra cosa y para el manejo de errores tenemos las excepciones que son mucho más poderosas y flexibles que un simple goto.
11/06/2009Joel dice:

Le encuentro mucho parecido a esta polémica a cuando algún “artista” famoso hace algo “indebido” sólo lo hacen para llamar la atención :D. No sé si PHP necesita la controversia.

EMHO me parece que agregar la sentencia GOTO es como darle un cuchillo a los niños. Quienes dicen que es cuestión de buenas prácticas tienen razón, pero si puedes hacer que tu lenguaje oriente al programador hacia ellas, que mejor. Es por eso que muchos se quejaban de Java diciendo que tenía “muchas restricciones”, aunque acepto que como todo, no es infalible y si uno quiere puede programarse todo en el main y nada de objetos (que es para lo que está hecho).

Al final del día (pochismo), tendremos algunos programadores que ni volteen a ver el GOTO como opción y por otro lado tengamos a otros que como siempre van a hacer sus cochinadas. Sí, las pueden hacer de todas maneras, pero ahora quienes mantienen código de otros tendrńa otra cosa más de que preocuparse como bien lo dices.

Saludos.
11/06/2009pablasso dice:

@levhita: excelente link, estoy 100% de acuerdo con todo lo que dice. Solo que yo me enfoco más en el punto que mencionan al final “there is a legitimate concern here that inexperienced programmers will use GOTO to the general detriment of their code”.

Si todos lo utilizaran como Timothy Boronczyk no me quejaría para nada.

Mi punto es que prefiero que un lenguaje te force a utilizar buenas prácticas (python ftw) a que intente solucionar la vida de todos.
11/06/2009levhita dice:

Considero que debería de aplicarse la ley del hielo en la documentación, ningún enlace o referencia hacia la documentación del GOTO… si alguien piensa hacer un compilador de compiladores o alguna máquina de estado finito seguramente está más que capacitado para saber que existe una cosa llamada GOTO y realizara una búsqueda explicita.

PD: Me saca de onda que sólo puede saltar a una etiqueta dentro de su ámbito de ejecución (bastante lógico y deseable), pero que las etiquetas deban de estar nombradas de acuerdo al namespace global.

“Each label must be unique. The programmer may soon find himself duplicating code and devising creative label names to handle the same type of errors in slightly different ways. Another drawback is that PHP requires the label to be within the same scope as the goto call.”

Lo más lógico sería que los nombres de las etiquetas sólo fueran únicos dentro de su ámbito de ejecución también.
11/06/2009levhita dice:

PD: No dice nada en la documentación sobre eso… así que tendría que hacer algunas pruebas antes.
11/06/2009Joel dice:

@levhita: sobre lo del ámbito de las etiquetas y nombrarlas de manera única tienes razón. Yo pienso que es que les dió flojera modificar la tabla de símbolos del namespace para manejarlo de manera única solo en el alcance local.

[modo broma="on"]
Tan fácil que era añadir un $ al final del código hash de las etiquetas en la tabla de símbolos de acuerdo a su ámbito; eso es lo que yo hice en mi clase de compiladores.
[/modo]

Saludos.

Escribe tu comentario:

Los mas frikis pueden suscribirse a los comentarios por RSS.