hacker


Ingresar con nombre de usuario, contraseña y duración de la sesión
| Portal Hacker | Editorial | Descargas | Ezine |
Inicio Ayuda Ingresar Registrarse
08 de ſeptiembre de 2008, 01:52:46
Noticias: La 1era E-Zine de CPH ya fue liberada, encuentrala
Para ver este enlace Registrate o Inicia Sesion
> aquí

+  Foros pOrtal Hacker
|-+  Programacion
| |-+  Desarrollo Web
| | |-+  Php (Moderador: shevchenko)
| | | |-+  ¿Que nos espera con PHP 6?
0 Usuarios y 1 Visitante están viendo este tema. « anterior próximo »
Páginas: [1] Ir Abajo Imprimir
Autor Tema: ¿Que nos espera con PHP 6?  (Leído 598 veces)
Gydion
NZ1
*
Desconectado Desconectado

Mensajes: 61


I Want To Known


Ver Perfil
« : 21 de ſeptiembre de 2006, 08:42:01 »

Qué nos espera con PHP 6?

Por Richard Davey

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 desarrolladore s.

El núcleo central de los desarrolladore s 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 desarrolladore s.

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 transcripcione s 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_s ybase y magic_quotes_g pc.

El modo seguro, también eliminado

¡Esto puede que les guste a los desarrolladore s 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á, (afortunadament e).

'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.

Extraido de:
Para ver este enlace Registrate o Inicia Sesion
En línea
Universal SAC
NZ3
***
Desconectado Desconectado

Mensajes: 583


Universal SAC


Ver Perfil
« Respuesta #1 : 22 de ſeptiembre de 2006, 05:53:58 »

Genial!!
Creo que se están haciendo cambios que a todos nos van a convenir, aunque no creo que esas pequeñas cosas (exceptuando Movimientos de las Extensiones) vayan a mejorar PHP mucho.
Estuve considerando también la opinión del autor en cuanto a el soporte para Unicode: 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.; llegué a la conclusión de que tiene razón... Considerando los datos de velocidad estando Activado y Desactivado, creo que es definitivo que es mejor que se haga por usuario y no a todo el servidor entero con la misma desición.  desepcion

Ese Register Globals, que bueno que lo quitan completamente de php pues creo que provoca muuuuuuuuuuuuu uchos y graves problemas de seguridad en aquellas webs que no están enteradadas del tema.  nuse

Un saludo Gydion, siempre me gustan los temas que colocas; espero y sigas haciendolo.
Gracias.
« Última modificación: 22 de ſeptiembre de 2006, 05:57:39 por Universal SAC » En línea

~UNIVERSAL[HACK]
Gydion
NZ1
*
Desconectado Desconectado

Mensajes: 61


I Want To Known


Ver Perfil
« Respuesta #2 : 23 de ſeptiembre de 2006, 06:12:19 »

Estoy contigo y con Richard Davey, no me gusta el tema de dejar el soporte de Unicode unicamente a cargo del servidor. Si que se gana velocidad de procesamiento, pero con la tecnologia actual, no debería de ser un problema.

Lo mismo con el Register Globals, es un gran avance en seguridad.

Tambien es bueno que al suprimir el "modo seguro" nos dejen el open_basedir.
En línea
Páginas: [1] Ir Arriba Imprimir 
« anterior próximo »
Ir a:  


Ingresar con nombre de usuario, contraseña y duración de la sesión

Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC hacker

Juegos gratis - Articulos PHP - Juegos - Trucos - Letras - Juegos - Juegos Online