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 Zend Engine 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.