¿Qué nos espera con PHP6?
El núcleo central de los desarrolladores de PHP tuvieron un encuentro en París el 11 de Noviembre de 2005 para discutir hacia donde marcharía PHP en el futuro. La transcripción completa del encuentro es una lectura fascinante, pero leerlo todo es un esfuerzo considerable. Por eso, os presentamos aquí los puntos clave que surgieron en la reunión y qué impacto pueden tener sobre vosotros, como desarrolladores. Antes de empezar es importante que quede clara una cosa: lo que aquí podáis leer no está garantizado de ninguna manera al 100% que se incorpore a PHP 6. Aún así, podemos entender la información de las transcripciones como el estado actual de las decisiones sobre un montón de cosas en el equipo de PHP.
Antes de empezar es importante que quede clara una cosa: lo que aquí podáis leer no está garantizado de ninguna manera al 100% que se incorpore a PHP 6. Aún así, podemos entender la información de las transcripciones como el estado actual de las decisiones sobre un montón de cosas en el equipo de PHP. (Pulsa en Leer Más para ver el artículo completo).
Unicode
El soporte de Unicode, en estos momentos, puede activarse bajo petición. Esto equivale a que PHP tenga que almacenar las variantes tanto Unicode como no-Unicode de nombres de clases, métodos y funciones en las tablas de símbolos. En resumen – usa más recursos. La decisión es hacer que los ajustes de Unicode afecten a todo el servidor, y que no sean bajo petición. Desactivar Unicode allí donde no es necesario puede mejorar el rendimiento, y se ha detectado que algunas funciones de cadena pueden ser hasta un 300% más lentas y que aplicaciones completas pueden ser un 25% más lentas por este motivo. La decisión para moverlo al php.ini en mi opinión, quita el control de las manos al usuario, y lo pone en las del Host Web.
Si compilas PHP tú mismo, o eres responsable de ello en tus servidores, puede que estés interesado en saber que PHP 6 va a requerir las bibliotecas ICU (esté Unicode activado o desactivado). El sistema compilado se paralizará sin las bibliotecas ICU necesarias no son encontradas. En resumidas cuentas, tendrás que instalar otra cosa más cuando quieras compilar PHP.
Register Globals es retirado
Decid adiós, amigos, esto finalmente se acaba. Ya no será un ajuste del fichero ini, y si se encuentra aparecerá un error E_CORE_ERROR, llevándote a la documentación sobre porqué es "malo". Esto significa que PHP 6 acabará con todos los scripts de la era de PHP 3 (o cualquier script que utilice globales registradas) sin otra opción que volver a escribirlos desde cero. Es una decisión dura, pero tenía que hacerse.
Las Magic Quotes también desaparecen
La característica de las "magic quotes" de PHP se elimina, y al igual que con register globals provocará un error E_CORE_ERROR si se encuentra en alguna parte. Esto afectará a magic_quotes, magic_quotes_sybase y magic_quotes_gpc. El modo seguro, también eliminado
¡Esto puede que les guste a los desarrolladores que tienen web hosts que insisten en el modo seguro! Pero ahora desaparecerá por completo, también provocando un error E_CORE_ERROR si se encuentra. La razón es que aparentemente daba una idea errónea, implicando que hacía a PHP seguro, cuando en realidad no mejoraba en nada la seguridad. open_basedir se conservará, (afortunadamente).
'var' significará lo mismo que 'public'
PHP4 usaba 'var' entre las clases. PHP5 (en su decisión OO) casusaba que esto mostrara una advertencia bajo E_STRICT. Esta advertencia será retirada en PHP6, y en su lugar 'var' significará lo mismo que 'public'. Es una buena decisión, pero si alguien ha actualizado sus scripts para que funcionen bajo E_STRICT en PHP5 será redundante para ellos.
Return by Reference dará un error
Tanto $foo =& new StdClass() como function &foo producirán ahora un error E_STRICT.
El modo de compatibilidad zend.ze1 eliminado
ze1 intentó siempre conservar el viejo comportamiento de PHP4, pero aparentemente "ni siquiera funciona al 100%", así que será eliminado por completo y dará un error E_CORE_ERROR si se detecta.
Soporte de Freetype 1 y GD 1 abandonado
Se elimina el soporte para estas (muy, muy antiguas) bibliotecas.
dl() sólo se mueve a SAPI
Cada SAPI registrará el uso de esta función como se requiera, sólo CLI y las SAPIs integradas harán esto desde ahora. No estará disponible en otro lugar.
FastCGI siempre activado
El código de FastCGI será renovado y estará siempre disponible para la CGI SAPI, no podrá ser desactivado.
Register Long Arrays eliminado
¿Recordáis las globales HTTP_*_VARS de hace tiempo? Bueno, si aún no estás usando $_GET, $_POST, etc – empieza a hacerlo ya, porque esta opción para permitir long arrays se elimina (y dará un error E_CORE_ERROR).
Movimientos de las Extensiones
Las extensiones XMLReader y XMLWriter serán desplazadas al núcleo de la distribución y estarán activadas por defecto.
La extensión ereg se mueve a PECL (y será eliminada de PHP). Esto significa que no se permitirá desactivar PCRE. Esto allanará el camino para la nueva extensión de expresiones basada en ICU.
La extensión tremendamente útil Fileinfo se desplaza al núcleo de la distribución y estará activada por defecto.
Autor: Juan Carlos Arango
Fuente: Septimo continente Virtual
