Manuales Gratis
La llegada de la versión 5 de PHP, aún la comunidad de desarrolladores de PHP se plantea el interrogante.
Las dudas básicamente circulan siempre el mismo camino, y ambas
elecciones tienen sus ventajas y desventajas. Intentaremos en este
informe orientar a los desarrolladores a decidirse por una u otra
alternativa.
Es importante remarcar antes de ubicarse de lleno en el análisis de
las ventajas y desventajas de una u otra opción, las principales
diferencias existentes entre ambas versiones, cuales son los cambios
que repercuten más fuertemente en la compatibilidad de los scripts, y
que es lo que nos depara el futuro en toda esta historia.
Cambios profundos
La llegada de PHP5 vino emparejada de una reestructuración del Core de PHP, lo que los creadores de PHP llama Zend Engine.
Así como el lejano PHP3 incluye su 0.5, y PHP4 el Zend Engine 1.0, tenemos Zend Engine 2.0 en PHP5. El
cambio de versión no fue trivial; incluye la reescritura casi total del
modelo de objetos, entre sus cambios más sustanciales.
Esto repercute directamente en los scripts de PHP4 que utilizan clases,
tanto en la compatibilidad como en performance de ejecución.
Posteriormente en este artículo nos referiremos nuevamente a este tema.
Veamos un ejemplo que nos muestra un cambio sustancial en la implementación del modelo de objetos:
<?
class Persona {
function setNombre($nombre) {
$this->nombre = $nombre;
}
function getNombre() {
return $this->nombre;
}
}
function Algo($p) {
$persona->setNombre("Daniel");
}
1 $persona = new Persona();
2 $persona->setNombre("Pichongol");
3 Algo($persona);
4 echo $persona->getNombre();
?>
¿Cuál es el problema en este código corriendo en PHP4?
En la línea 1 instanciamos un objeto de la clase Persona.
Luego le decimos que se llama Daniel.
El error de implementación viene con la línea 3. El argumento $p
que recibe Algo, no es mas que una copia de $persona, y eso esta MAL.
¿Porque?, mínimamente por 2 razones.
La primera razón es que esta estrategia es POO-No compatible.
Claramente cuando hablamos del Paradigma Orientado a Objetos, estamos
casi descartando que cada objeto sea referenciado por su Identificador.
Sin embargo, el Zend Engine 1.0 no está preparado para dicha acción:
<?
function ejemplo($val){
echo $val;
}
$cadena = "texto";
ejemplo($cadena);
?>
La variable $cadena pasada como argumento a la función ejemplo, es
copiada para su uso local dentro de dicha función. Es lo que se conoce
como paso de parámetros por valor.
El Zend Engine 1.0 hace exactamente esto para todas las funciones,
inclusive para las que están dentro de una clase, las cuales en ese
caso actúan como métodos:
<?
function Algo($persona) {
$persona->setNombre("Daniel");
}
?>,
Volviendo al ejemplo inicial de la clase persona, el método Algo recibe una copia (un clon) del objeto Persona.
La segunda razón viene emparejada con la primera, siendo consecuencia de esta.
Cualquier modificación del objeto Persona que se produzca dentro
del método Algo, solo tendrá alcance local, y no se verá reflejado
cuando la función retorne.
<?
Algo($persona);
echo $persona->getNombre();
?>
En ese caso la modificación del nombre que hace la función Algo al
objeto Persona no se ve reflejada cuando hacemos echo
$persona->getNombre().
En nuestro browser veremos "Pichongol".
Este es solo un ejemplo del porque de la reestructuración tan
importante en el Core de PHP. Es claro que toda reestructuración barre
con cuestiones de compatibilidad, para ganar en otros skills; en este
caso claramente estamos ganando en performance, al liberarnos del
overhead que implica la constante copia de objetos que son argumentos
de métodos y funciones.
En artículos posteriores trataremos en mayor detalle y profundidad
los distintos aspectos que fueron modificados, haciendo una comparativa
entre como se logran en PHP4 y como se logran en PHP5. Además de
explicar profundamente las diferencias en el modelo de objetos nos
quedan temas pendientes como Opciones de configuración (php.ini),
Conexión a MySQL (mysqli), cambios en los módulos, etc.
Hecha esta introducción, estamos en condiciones de definir las
distintas situaciones en las que se puede encontrar el desarrollador, y
que aspectos juegan a su favor o en contra según la situación en la que
se encuentre.
¿Cual es mi escenario?
En el momento de plantearse la pregunta, el desarrollador seguramente se ubicará en alguno de los dos escenarios posibles:
" Newbie (Iniciación en PHP).
" Experimentado.
Newbie
En el planteo de esta discusión, podríamos decir que es la
situación ideal, o por lo menos la más beneficiosa. Si eres una persona
que quiere arrancar en PHP, no lo dudes, PHP5 es para ti. Tus
aplicaciones gozaran de las nuevas capacidades en OOP, obtendrás el
beneficio de una mejor performance de ejecución (esta comprobado
experimentalmente que PHP5 corre un 25% más rápido que PHP4) y tu
código estará muy bien acondicionado en cuanto a la compatibilidad con
el nuevo hijo que asoma: PHP6.
Por cierto, no todo es color de rosas. Una de los mayores
beneficios a la hora de elegir PHP para trabajar en nuestro proyecto es
la gran cantidad de código que podemos encontrar en Internet, y
utilizarlo para nuestros trabajos. Tenemos una gran probabilidad de que
ante alguna tarea que se nos plantea, podamos encontrar algún script
que nos solucione la vida, obviamente adaptándolo a nuestras
necesidades.
Ahora bien, no todo el código que vamos a encontrar es compatible
con PHP5. De hecho la gran mayoría todavía no se ha adaptado. Es cierto
que con algún setting en nuestro php.ini podemos ayudar a darle mayor
compatibilidad, pero como contrapartida muchas de estas settings se
eliminaran en PHP6.
¿Qué queda? Hacerlo compatible modificando el código, una tarea
que para un desarrollador que se inicia no siempre es sencillo. De
todas formas a no alarmarse, que los grandes proyectos (PHPNuke, PHPBB, etc.) ofrecen compatibilidad.
Experimentado
En este caso, el optar por quedarse con PHP4 o pasar a PHP5 depende de nuestra aplicación.
Las interrogantes que el desarrollador se puede plantear podrían ser:
- ¿Mi aplicación usa clases y objetos?
- ¿Mi motor de Base de datos es MySQL?
- ¿Utilizo un hosting externo?
- ¿Mi aplicación sufre modificaciones en cuanto a los requerimientos y lógica de negocios?
Pasemos a discutir ventajas y desventajas en cada uno de los interrogantes:
¿Mi aplicación usa clases y objetos?
Como pudimos comprender al comienzo de este articulo, uno de los
principales esfuerzos de los diseñadores del Zend Engine radicó en el
mejoramiento del modelo de objetos, basándose claramente en un
referente indiscutible en esta materia como lo es Sun. Salvando las diferencias, se han tomado muchas cosas de Java, desde convenciones de nomenclaturas hasta estrategias de implementación.
Seria un desperdicio no utilizar dicho esfuerzo, sobre todo si nuestra aplicación hace un uso exhaustivo de clases y objetos.
¿Mi motor de Base de datos es MySQL?
A diferencia de la estrategia de PHP4 para la conectividad PHP/MySQL,
en la que el Core de PHP nos provee de un set de funciones para dicha
interacción, en PHP5 MySQL nos provee de un API externo.
Básicamente, la razón de este cambio fue una modificación de
licencia de MySQL, que obligo a PHP a hacer de MySQL una base de datos
más, y no "LA" base de datos, como venia siendo en PHP3 y PHP4.
De todas formas, esto no repercute en nuestro código, sino en la performance de nuestra aplicación.
El hecho de que una extensión no forme parte del Core de PHP y pase
a ser externa nos genera un overhead, una sobrecarga de ejecución en
detrimento de la performance.
Como contrapartida, PHP5 nos da la posibilidad de sacarle el mayor
jugo posible a las muchas mejoras incorporadas en MySQL 4.1.3 o
superior, a través del API mysqli.
Esto implica hacer uso de otras funciones, modificando nuestro código.
Ahora bien, ¿que tan costosa es esta reescritura? Dependerá de
nuestra estrategia de conexión a base de datos. ¿Utilizamos una capa de
abstracción del estilo ADOdb ? Si la utilizamos estaremos mucho mejor parados frente a tal
reescritura. En caso contrario el tiempo invertido será sensiblemente
mayor.
¿Utilizo un hosting externo?
En caso de no disponer de un hosting propio, y tener que depender
de un hosting externo que nos provea de PHP, seguramente el hecho de
pensar en migrar a PHP5 puede ser un problema. De hecho, estadísticas
de principio de 2006 nos indican que solo alrededor del 5% de los
hosting que proporcionan PHP, tienen PHP5.
Esto no hace mas que reflejar la lentitud con la que se esta moviendo el proceso de traspaso de PHP4 hacia PHP5.
Una pregunta que surge directamente sobre este tema es ¿Por qué?
Bueno, si uno tomo una distribución de Linux, es poco probable que la versión de PHP5 sea la incluida.
La conformidad de los programadores con PHP4 es grande, y mucha de la documentación existente esta escrita para PHP4.
De todas formas, a no dormirse con PHP4. Un tema que se trata en la
segunda parte de este artículo es lo nuevo que nos trae PHP6. Veremos
que PHP5 en muchos aspectos es una transición mientras que la
confirmación se llama PHP6.
¿Mi aplicación sufre modificaciones en cuanto a los requerimientos y lógica de negocios?
Cuando las aplicaciones tienen requerimientos de cliente bastante
cambiantes, y se emplean recursos para su mantenimiento, o utilizamos
una metodología de desarrollo incremental (software versionado), lo
ideal es utilizar lo último que nos proporciona nuestra plataforma de
programación. Generalmente lo que se busca es un cambio gradual,
modular, y sostenido.
Por otro lado, si nuestras aplicaciones residen en producción sin
mayores modificaciones (algún proceso batch, alguna aplicación
depurada, algún algoritmo estable) y estamos conformes con su
funcionamiento, quizás no sea de nuestro interés migrar hacia una nueva
versión.
Nos queda analizar que hay de nuevo en PHP6 y que cosas deberíamos ir teniendo en cuenta si utilizamos PHP4 o PHP5.
Enlaces: |
