¿Qué nos espera con PHP 6?

10.08.2006

¿Qué nos espera con PHP 6?

Por Richard Davey | 22,282 Lecturas
Archivado en: PHP

Existen varios puntos para tomar en cuenta acerca de PHP en el futuro, en el presente artículo hablaremos un poco acerca del impacto que pueden tener estos puntos para los desarrolladores.

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.

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.

¿Qué otros puntos consideran ustedes que deben tomarse en cuenta con PHP en el futuro?

Este artículo fue publicado originalmente en phpsolmag.org por Richard Davey.

Califica esta nota:

(6 votos, promedio: 4.83 de 5)

Loading ...

Sobre el autor

Richard Davey
Programador con el certificado Zend. Trabaja sobre todo con las aplicaciones relacionadas con los juegos de vídeo. Tiene su propio blog dedicado a PHP. Vive con su esposa en Inglaterra.

Comentarios

22 comentarios en total.

Miguel 12.08.2006 - 06:15 - #

gracias por este resumen. muy bueno
wilder 16.08.2006 - 17:31 - #

Bien por la seguridad que php propone, al eliminar los register globals, bueno yo nunca los use pero lei en muchos lugares las vulnerabilidades que tenian, que bien.

Muy buen resumen, gracias
DIego Rosado Pino 25.08.2006 - 10:58 - #

Me parece una real pendejada, aunque por lo de register globals, si era un factor de inseguridad, vi por ahi un ejemplo en php6 de como cambiaria algo la prog, y note q era mucho codigo, solo para realizar unas cuantas impresiones. Será un terrible dolor de cabeza aumentar codigo para hacer algo minimo. ñ_ñ
DAVID RAMIREZ 25.08.2006 - 14:55 - #

Ahora para los programadores el lema debe ser: es adaptarse o morir!!! (Si no preguntenle a los viejos programadores de COBOL, CLIPPER,VISUAK, etc… muy buenos en sus tiempos)

Amigo Diego Rosado te invito a revisar a fondo el código PHP6 creo que estas equivocado y no has tenido suficiente información sobre ello…

Siento que cambiar a PHP6 es un poco precipitado… En lo personal me gusta mas JAVA (JSP), que tan bueno será que otros Lenguajes como ASP-net, PHP5-6, RUBY, etc. se han apoyado en él para evolucionar. Saludos…
Stuardo -StR- RodrÃguez 05.09.2006 - 15:07 - #

¿Quien de ustedes ya programa en PHP5? Los invito a que lo prueben y aprendan cosas nuevas. PHP6 viene mucho mejor, no para complicar las cosas. Complicado lo mira la gente que no entiende o no sabe.

Los invito a participar del grupo de PHP en Guatemala - http://php.develsystems.com
TelandWeb 07.09.2006 - 10:08 - #

Pues elimina drasticamente lo que desde php3 teniamos.

Pero muy bueno por el tema de seguridades.

A mi me ha tocado migrar casi todos mis sitios a PHP5, dado que contraté un servidor con esta configuracion.

El paso fue bonito, el primero si fue fuerte el cambio, pero como usaba un mismo script base para todo, el cambio fue realmente sencillo.

Asi que el paso a php6 no será complicado. Al menos no se ha de sentir mucho como lo fue con el php5.

// http://www.telandweb.net //
Marko 15.09.2006 - 13:51 - #

Pues al ver estos poco puntos puedo apreciar que PHP6 es un PHP5 más estilizado. La duda que tendría, sería… qué llevaría a los desarrolladores llamarle a esta versión nueva como PHP6 y no como PHP5.x, no encuentro o no se me hace claro el gran motivo para la desición. Muy buena resumen por cierto!
Camilo 17.09.2006 - 17:17 - #

Yo la verdad estoy de acuerdo con todos los cambios, la verdad ni me afectan puesto que siempore he trabajado como se debe, tomando las debidas precauciones de alamacenas las varaibles de los formularios en otras variables y no firarme del register globals, y etc etc, en fi, para una persona precavida estos cambios no traeran mayores problemas, un saludo
cvander 18.09.2006 - 23:47 - #

Realmente vemos que PHP6 nos traerá una mayor madurez para el lenguaje y muchas mejora que han oido de la comunidad.

Claro que será un reto en varios aspectos acostumbrarse a algunos cambios, pero al estar bien fundamentados será un paso que se dará fácilmente, como ya ocurrió con anteriores versiones.

Por cierto, alguién que maneje muy bien PHP en su versión 5 y haya tenido oportunidad de trabajar con Ruby on Rails? He visto que varios están migrando hacia este lenguaje y no se si con la versión 6 veremos que se toman caminos diferentes o que se reafirma que las cosas seguirán mucho mejor para los phperos.
Mulato 16.10.2006 - 10:08 - #

Es un salvavidas para los que programa bajo el esquema de PHP 4…
Marlon 29.10.2006 - 09:02 - #

Muy buen resumen, gracias
Raul 31.10.2006 - 09:39 - #

Pues espero que el cambio valga la pena. Pero al menos por el momento yo me quedo con PHP 5…ya he surido lo suficiente migrando desde 4.x…
Samuel Guzman 10.11.2006 - 21:01 - #

Interesante, entonces si quiero migrar a la nueva version tengo que revisar y/o reprogramar las miles de lineas de codigos que contienen los programas que he hecho hasta ahora? rayos.. no es una papa. (pero como dice el dicho, no hay mal que por bien no venga). pa lante.
facundo 08.12.2006 - 12:37 - #

aaa que pinturita esto de php6 … lo que nos espera …. espero que sea para bien. pero tambien hay aplicaciones que se tienen que adapatar a este cambio…. no?…
pedro 25.12.2006 - 20:18 - #

es una alternativa interesante la migracion a php6 ¿los cambios seran radicales?
juan 25.12.2006 - 23:56 - #

Hola. ¿Y que pasa con la redefinicion de funciones en php6 ? ¿Se podra hacer o no?
Manuel 21.02.2007 - 10:06 - #

¿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).

——————————————————-

Seguramente van a decir que soy arcaico pero a mi me gusta usar HTTP_*_VARS porque siento que el codigo es mas legible, snif, habra que cambiar.
fishman.cu 23.10.2007 - 07:07 - #

El resumen estuvo muy bueno y esplicito, pero me pregunto si hay alguna intencion de entrarnos en el mundo de la Programacion Orientada a Aspecto, q muchops piensan q es un concepto bobo pero a mi me resolberia muchos problemas.
juan 30.12.2007 - 09:21 - #

@fishman.cu

como escribir correctamente “resolver”?
LOL
Modorro 23.06.2008 - 14:07 - #

muchas gracias por el porte, yo utilizo HTTP_POST_VARS
hay que cambiarlo antes de que tire errors
Raul Anguiano Gnadinger 26.06.2008 - 12:56 - #

Interesantes cambios los que nos esperan con PHP 6 y excelente resumen, gracias!.

bondezire!
RAG
yea 30.07.2008 - 23:33 - #

como php4 no hay ninguno, mejor version que esa es complicado.

php6 sera lo que tape el error tan grande que es php5, una cortina de humo.

cambios, pues para 4 cambios subir de revision completa, no tiene mas sentido que el mencionado, con lo bien que estabamos en php4.

bueno, yo ahora estoy en 5, pero sigo programando en 4, la diferencia es poca