Nueva versión de PHP 5.4

[andresdzphp]

El equipo de desarrollo de PHP está orgulloso de anunciar la inmediata disponibilidad de PHP 5.4.0. Este lanzamiento es un gran paso adelante en la serie 5.x, que incluye un gran número de nuevas características y correcciones de errores.

Gracias GatorV:
PHP 5.4 será la última serie compatible con Windows XP y Windows 2003. No vamos a ofrecer los paquetes binarios para estas versiones de Windows después de PHP 5.4.

- Nuevas sintaxis:

http://docs.php.net/manual/en/migrat...w-features.php

Entre las que más me llaman la atención los traits y la sintaxis corta de los array

A partir de PHP 5.4 también se puede utilizar la sintaxis de array corta, que sustituye a array () con [].

Ejemplo:

Código PHP:

// desde PHP 5.4
$array = [
    "foo" => "bar",
    "bar" => "foo"
];
 

y también se puede hacer esto:

Código PHP:

<?php
function getArray() {
    return array(1, 2, 3);
}
 
// en PHP 5.4
$secondElement = getArray()[1];
 

- Mejora del rendimiento y el consumo de memoria reducido

- Limpieza del código base, eliminación de múltiples características del lenguaje obsoletas

- Más o menos 100 bugs corregidos.

- Las directivas Register globals, magic quotes y safe mode fueron eliminadas

- La sintaxis break/continue $var fué eliminada

- La opción ini allow_call_time_pass_reference fué eliminada

- El default_charset de PHP es ahora "UTF-8"

- La sintaxis <?= está disponible sin importar la directiva short_open_tag

- Nuevo Built-in web server para propósitos de desarrollo

- Eliminado el soporte de putenv("TZ = ..") para establecer la zona horaria.

- Eliminadas las funciones session_is_registered(), session_register() y session_unregister().

- Añadido soporte para la sintaxis: Class::{expr}()

- Añadido soporte de closure $this

- Añadido soporte para eliminar referencias de array

- Añadido el soporte de acceso de los miembros de clase sobre la creación de instancias (new foo)->bar()

- Cambiada la conversión de array a string silenciosa a producir un error de tipo notice

- E_ALL ahora incluye los tipos de error E_STRICT

- Nueva función hex2bin

- Añadido soporte para SORT_NATURAL y SORT_FLAG_CASE en las funciones de ordenamiento de arrays (sort, rsort, ksort, krsort, asort, arsort and array_multisort).

- Mejorado el rendimiento de unserialize().

- Añadido $_SERVER['REQUEST_TIME_FLOAT'] para incluir precisión de microsegundo.

- Añadida la función http_response_code()

- Añadida la directiva max_input_vars para prevenir los ataques basados ​​en colisiones de hash.

- cURL: añadido soporte para CURLOPT_MAX_RECV_SPEED_LARGE y CURLOPT_MAX_SEND_SPEED_LARGE

- DOM: Añadida la capacidad para pasar opciones al loadHTML

- mysql_list_dbs obsoleto

- PDO_mysql: Se ha eliminado el soporte para enlazar con las bibliotecas de cliente de MySQL anteriores a la 4.1.

- Arreglada la incompatibilidad binaria de objetos PDO

- Tercer parámetro de preg_match_all() ahora es opcional

- Añadido soporte para manejadores de sesión orientados a objetos

- Nuevas funciones trait_exists(), get_declared_traits(), stream_set_chunk_size(), socket_import_stream(), getimagesizefromstring(), header_register_callback(), session_status(), session_register_shutdown()

Entre otras cosas

http://php.net/releases/5_4_0.php

Esta parte en construcción pero se las dejo:

Migrando de PHP 5.3.x a PHP 5.4.x

Registro de cambios
http://php.net/ChangeLog-5.php

[CesarHC]

Por fin:

- Las directivas Register globals, magic quotes y safe mode fueron eliminadas

- El default_charset de PHP es ahora "UTF-8"

Que continue la evolucion .

[masterpuppet]

De esta versión lo que mas me interesa es el ver el efecto en lo fw's y librerias del "compiler assisted copy & paste"(aka traits) teniendo en cuenta el creciente interés en AOP.
Viendo la lista de features le han agregado un par de cosas interesantes, habrá que ver cuanto demora la comunidad en dar el salto.

Saludos.

[abimaelrc]

Ufff con traits, van a ver muchos que lo van a sobre usar, vamos a ver cuantos temas se acumularan en el foro usando desmedidamente traits

[pateketrueke]

Pues a mi se me ocurren bastantes cosas fancy para implementar en mi framework, de hecho creo que siempre he estado esperando tal versión para darle el boost final que necesitaba.

Si les interesa estar al tanto ya saben que pueden consultar mi GitHub cuando deseen.

[GatorV]

Esto también es bueno creo, hay que empezar ya a usar sistemas operativos más recientes:

PHP 5.4 will be the last series to support Windows XP and Windows 2003. We will not provide binary packages for these Windows versions after PHP 5.4.

[gildus]

Lo mas notable que me gusta son los traits y Built-in web server.

[novatoide]

Viva la evolución jeje ! que buena noticia y que bueno lo de charset utf-8 :D

Abrazo.-

[Papito18]

Al parecer la funcion import_request_variables("Metodo de envio","Prefijo") ha sido eliminada.

Saben que funcion utilizar en lugar de esta porque la verdad a mi me parecia muy util.

Saludos.

[pateketrueke]

Iniciado por Papito18

Al parecer la funcion import_request_variables("Metodo de envio","Prefijo") ha sido eliminada.

Saben que funcion utilizar en lugar de esta porque la verdad a mi me parecia muy util.

Saludos.

Si se te hacia útil es porque tal vez seguías trabajando como hace mas de 10 años, ya que la forma oficial y estable siempre ha sido la siguiente:

Código PHP:

  $_GET['variable'];
$_POST['variable'];
$_REQUEST['variable']; 
   

¿O en qué casos podrías ejemplificar su verdadera utilidad sin re-inventar la rueda?

[dashtrash]

Traits...Después de años y años defendiendo que la herencia múltiple es necesaria, ante la horda de Javeros...Me alegra ver que finalmente se entra en razón (las diferencias con la herencia múltiple son mínimas)..
Tanta gente diciendo que si "necesitaba hacer tal o cual cosa, es que no entendía OOP"...
En cualquier caso, la herencia múltiple es más útil en lenguajes tipados..Lo bien que le vendría a PHP un repaso para poder tipar y sobrecargar métodos..

Sin embargo, me sigue pareciendo que la herencia múltiple es más limpia que los traits.

[abimaelrc]

Iniciado por Papito18

Al parecer la funcion import_request_variables("Metodo de envio","Prefijo") ha sido eliminada.

Saben que funcion utilizar en lugar de esta porque la verdad a mi me parecia muy util.

Saludos.

En el manual dice que se puede usar extract ¿no es lo que quieres? Ademas, muy mala practica como ya te comentaron.

[GatorV]

El problema de la herencia múltiple y que estoy de acuerdo es cuando los métodos se llaman igual, entras en ambigüedad, aparte de que muchos programadores inexpertos empiezan a hacer cosas muy bizarras, es un arma de dos filos.

Pero es mejor tener la opción, a no tenerla

[Girlee]

se ve muy bueno

[dashtrash]

Iniciado por GatorV

El problema de la herencia múltiple y que estoy de acuerdo es cuando los métodos se llaman igual, entras en ambigüedad, aparte de que muchos programadores inexpertos empiezan a hacer cosas muy bizarras, es un arma de dos filos.

Pero es mejor tener la opción, a no tenerla

Pero ese problema también existe con traits.Solución: meter sintaxis para solucionar la ambiguedad.
Y, en ese sentido, no me gusta demasiado la sintaxis que usa PHP.Me parece algo completamente "fuera" del lenguaje.Es una construcción extraña.Hay ya elementos de resolución de ámbito en cosas como llamadas estáticas, constantes, etc..podrían haber usado algo de ese tipo, en vez de un bloque "ad-hoc"..
Y..si la herencia múltiple permite hacer cosas bizarras..Prepárate con los traits..Ten en cuenta que la única diferencia entre traits y herencia múltiple, es la forma de resolución de la herencia.El resto, es igual..Todas las barbaridades posibles con herencia múltiple, son posibles con traits.
Pero, digo que prefiero herencia múltiple, porque al ser un paradigma de OOP, uno hereda una clase diseñada con los criterios de encapsulación y visibilidad propios de OOP.
Con traits, no.Es la clase que usa un trait, la que define su visibilidad.Y, a la vez, un trait "ve" las variables privadas de la clase en la que se usa (!!! puerta abierta al desastre), con lo cual, no existe concepto de encapsulación y/o visibilidad impuesto por el código heredado.
Tú puedes hacer un trait que mantenga el estado interno de un proceso, "pensando" que los métodos que hagas, van a ser privados, y eso es uno de los pilares de la OOP.
Pero un trait no es OOP..nada impide que otra clase los importe como públicos..
Y, ya que un trait tiene visibilidad sobre variables y métodos que no posee, ya estoy viendo traits "suponiendo" que van a ser importados por la clase A y B, que tienen esas ciertas variables o métodos..Pero cuando lo importas desde C....

Yo programo OOP, que la prefiero a AOP...Y creo que es importante mantener el paradigma..La gente al final lo usará como "feature", sin decidir si su modelo de programación va a ser OOP o AOP...
Vamos..Que la programación bizarra posible con traits, no es para nada inferior a la posible con herencia multiple..

[pateketrueke]

A mi, en lo personal, me gustan los Traits.

Sobre todo porque también manejo lenguajes que no se parecen mucho a PHP, como Ruby, dónde el concepto de patchy-monkey es una realidad.

Traté de leer con calma lo que dices pero me he quedado igual, supongo que cientos de discusiones ya se habrán dado en los internals de PHP para definir dicho rumbo.

No entendí si estás a favor o en contra de los Traits, lo digo porque tu forma de redactar no me es tan clara.

[dashtrash]

No estoy ni a favor ni en contra.Prefiero herencia múltiple, porque es OOP. Traits no lo es.Es un paradigma distinto, y acabará mezclado.
Mira este código:

Código PHP:

trait muylisto {
    public function sayHello() {
        $this->myHello();
    }
}
class prueba
{
    use muylisto;
    private function myHello()
    {
       echo "HOLA";
    }
}
$c=new prueba();
$c->sayHello();
 

El trait "muylisto" está presuponiendo que la clase en la que se use, va a existir la función "myHello".
Ese código es perfectamente válido, y anti-OOP.
El equivalente es como si una clase base supiera a priori en qué clase va a ser usado (sin necesitar implementar un interfaz, o declarar el método como abstracto, o forzar de alguna forma a quien lo vaya a usar).
Puedes decir "bueno, sólo hay que tener cuidado, claro"...Pero, si siempre se tuviera cuidado, no haría falta ni "private","protected",etc,etc

Supongamos que la clase que usa el trait, no implementa la función.En qué momento se detectaría el problema? Cuando se ejecute el código.
En qué momento se detecta el problema de que una clase derivada no implementa un interfaz? En tiempo de parseo (a lo más que puede aspirar un lenguaje interpretado).Es una gran diferencia.

[pateketrueke]

Eso que dices suena a que únicamente programas para las maquinas, olvidando que la programación también debe ser entendida por los humanos, quienes leemos programas.

Lo de "es como si una clase base supiera" no es buen argumento serio, las clases no saben ni deberían saber, en todo caso es el programador el que decide que Traits usar y dónde.

Suenas a todo un OOP-purista y eso es extraño, sobre todo al hablar de un lenguaje que no es 100% OOP, así que por definición ni siquiera deberías usar PHP al proclamarte practicante estricto de OOP.

Mira, yo por ejemplo necesito de esto:

Código PHP:

  class Foo {} 
   

Y quiero que dicha clase Foo puede recibir y emitir eventos, pero no quiero heredar nada simplemente porque no quiero aplicar ningún concepto de herencia aquí, únicamente funcionalidad o razgos.

Código PHP:

  class Foo {
  use Eventable;
} 
   

Entiendo y comprendo las ventajas de la herencia, pero en este caso no aplican ya que el contexto es claro, únicamente poseo un Trait para agregar dicha funcionalidad a mi clase, y aunque pude conseguir el mismo efecto usando herencia ¿de que me he perdido por no usarla?

No veo la perdida y la ventaja sigue ahí.

Para mi es una característica bastante interesante y claro que tiene mucha relación con OOP.

[dashtrash]

Iniciado por pateketrueke

Lo de "es como si una clase base supiera" no es buen argumento serio, las clases no saben ni deberían saber, en todo caso es el el programador el que decide que Traits usar y dónde.

Y, por lo tanto, no es necesario ni private, ni protected, cosa que ya mencionaba en mi anterior post, porque esa es la única posible respuesta.
No es necesario el concepto de encapsulación ni ocultamiento.Es el programador el que decide a qué función llamar, y cuándo.
El problema es que el "argumento no serio" es lo que ha llevado a que sean los paradigmas como oop, los patrones de diseño, el código, y, a ser posible, el compilador, el que detecte cuándo el programador quiere saber más de lo que debe.

Iniciado por pateketrueke

Suenas a todo un OOP-purista y eso es extraño, sobre todo al hablar de un lenguaje que no es 100% OOP, así que por definición ni siquiera deberías usar PHP al proclamarte practicante estricto de OOP.

Ahora, eres tú el que habla para las máquinas.Puedes aplicar un paradigma, independientemente de que un lenguaje te ofrezca todo el soporte posible para ese paradigma.Tú programas en ruby, yo en C++, donde sí hay soporte para estas cosas...Yo no me proclamo practicante estricto de OOP, pero, aunque lo fuera, no entiendo porqué me dices que no debo usar un lenguaje...Creo que eso es algo que elijo yo...creo..

Iniciado por pateketrueke

Y quiero que dicha clase Foo puede recibir y emitir eventos, pero no quiero heredar nada simplemente porque no quiero aplicar ningún concepto de herencia aquí, únicamente funcionalidad o razgos.

Eso sí que es un argumento poco serio.No usas herencia porque no quieres aplicar ese concepto...Como si la herencia "fuese algo más" que la funcionalidad..
Creo que hay cientos de clases que emiten o reciben eventos, y funcionan perfectamente con herencia...No veo qué me quieres mostrar...

Para mi es una característica bastante interesante y claro que tiene mucha relación con OOP

Explícame bajo qué condiciones, mi anterior ejemplo puede considerarse OOP.

[dashtrash]

Otro ejemplo:

Código PHP:

trait uno {
    public function A()
    {
       $this->h=1;
       $this->B();
    }
    private function B() 
    {
       $h++;
       echo $h;
    }
}
trait dos {
 
    public function A()
    {
       $this->h=3;
       $this->B();
    }
    private function B() 
    {
       $this->h--;
       echo $this->h;
    }
}
 
class prueba
{
    use uno,dos {
        uno::A insteadof dos;
        dos::B insteadof uno;
    }
}
 
$c=new prueba();
$c->A();
 

Qué valor se imprime?
Cero (0)
La clase que usa los traits, está alterando el funcionamiento interno de los mismos...Esto es un antipatrón OOP.

[pateketrueke]

¿Relación con cual OOP?

Si es estricto, no se bien, pero en PHP donde el OOP imperfecto es la intención sí.

Tu ya has hecho esa comparación, según el OOP puro (no sé cual) que usaste como referencia usar Traits es anti-OOP. Según el modelo OOP implementado en PHP es perfectamente válido.

Ahora, que sea incorrecto (según X punto de vista) pero a la vez válido (según Y punto de vista) no le resta merito ni lo convierte en falaz.

[pateketrueke]

La clase que usa los traits, está alterando el funcionamiento interno de los mismos...Esto es un antipatrón OOP.

Bueno, igual puedes forzar el peor comportamiento de los Traits únicamente para demostrar que son una total aberración de OOP, pero sólo estarás forzando dicha opinión.

Iniciado por Manual de PHP

Un Trait es similar a una clase, pero con el único objetivo de agrupar funcionalidades muy específicas y de una manera coherente.

Pienso que de usar Traits lo tenemos que hacer bajo las mejores prácticas, lo mismo que con OOP, ya que por muy buen paradigma o solución aún se pueden hacer mal las cosas.

[dashtrash]

Confundes la herramienta (PHP), con el paradigma (OOP).
Si a OOP, le quitas que una clase es responsable de mantener sus datos, su estado, y la visibilidad de los mismos..No sé qué OOP, pura o impura, te queda.De hecho, nunca había oído que existía OOP "pura" e "impura"..

En el ejemplo anterior, la clase "prueba" está decidiendo qué cosas importa del trait uno, y del trait dos.Por lo tanto, es responsabilidad de la clase "prueba" el que tanto el trait "uno" y "dos" sigan siendo funcionales.
Cómo sabe el programador si usar la función "B" del trait "dos" es compatible con la función "B" del trait "uno"?
Que aún se puede llamar a la función "A" del trait "uno"?
Mirando el código de ambos traits.

Es más, si la clase que usa un trait, define una variable miembro como **privada**..pero un trait puede modificarla cuando quiera..exactamente, qué tiene eso de OOP?
Todo esto no ocurre con herencia múltiple, por cierto.

Los traits son *AOP*, no *OOP*.Que PHP está metiendo AOP, OOP, closures, todos los paradigmas posibles...pues si..Y, como ya decía, lleva a la confusión.

[pateketrueke]

Es más, si la clase que usa un trait, define una variable miembro como **privada**..pero un trait puede modificarla cuando quiera..exactamente, qué tiene eso de OOP?

En el plano conceptual, al momento de usar un Trait es prácticamente como si copiáramos y pegáramos dicho código dentro de nuestra clase.

Eso evidentemente resuelve el tema de acceso y visibilidad, porque no es un entidad ajena, es por ello que entonces puede modificarse cualquier miembro de la clase host. No es lo mismo cuando heredamos, y eso ya lo sabes.

Por eso el manual dice que hay que implementar métodos coherentes, y a sabiendas de las implicaciones que esto conlleva no debería ser difícil.

Todo esto no ocurre con herencia múltiple, por cierto.

En eso tienes toda la razón, por eso digo que PHP tiene un modelo "impuro" (o mejor dicho incompleto) de OOP y al no ofrecer dicha funcionalidad de manera natural es que implementa los Traits.

Y pienso que sigue siendo OOP porque dichos traits está diseñados únicamente para intervenir objetos.

[dashtrash]

Iniciado por pateketrueke

Bueno, igual puedes forzar el peor comportamiento de los Traits únicamente para demostrar que son una total aberración de OOP, pero sólo estarás forzando dicha opinión.

"Forzar una opinión" es escribir código perfectamente válido? Vaya, yo creo que estoy usando la herramienta que, según dicen, evita los problemas de ambiguedad de la herencia múltiple...
Por cierto, con OOP, se puede evitar eso sin ningún problema.Con traits *no*.

Y, forzada o no forzada, es una cuestión de tu subjetividad..Lo que es objetivo, es que con traits, puedo saltarme tanto el encapsulamiento, como la visibilidad de la OOP.Eso es un *hecho*.Estaría gracioso que una herramienta que ayude a la OOP, se salte dos de los pilares de la misma, no?

[dashtrash]

Iniciado por pateketrueke

En el plano conceptual, al momento de usar un Trait es prácticamente como si copiáramos y pegáramos dicho código dentro de nuestra clase.

Eso no es *exacto*, y perdona si soy purista,pero tiene un motivo..Lo que es exacto es que copiamos y pegamos el código dentro de *todas las clases que usen ese trait*.

Es decir, si la clase A y B implementan el trait C, se modifique A, se modifique B, o se modifique C, sea por el mismo programador, o sea por distintos programadores, el "código pegado" tiene que seguir siendo "compatible".
Para estar 100% seguro que puedes usar 2 traits distintos(digo 100% seguro), no te queda más remedio que ir a mirar el código de ambos, y asegurarte de que no van a interactuar,ni entre ellos, ni con la clase que los use, de forma inesperada.

De nuevo, que eso lo tiene que saber el programador...claro..Si hay algo por lo que pongo la mano en el fuego en este mundo, es porque un programador siempre sabe lo que tiene que saber...

Iniciado por pateketrueke

Y pienso que sigue siendo OOP porque dichos traits está diseñados únicamente para intervenir objetos.

Yo conocía de la OOP la encapsulación, visibilidad, sobrecarga, interfaces, herencia...pero no la "intervención"...
Si no pasa nada! No es OOP! es AOP! No es más que eso!

[dashtrash]

Bueno, por dejarlo ya, una cosa curiosa, que además me afecta a mí, como programador que no hace lo que debe hacer .

Qué ocurre si dos traits declaran la misma variable como privada?

Código PHP:

trait uno {
    private $h;
    function one(){$this->h=1;}
    }
trait dos {
    private $h;
    function two(){$this->h=4;}
    }
 
class prueba
{
    use uno,dos;
}
 

PHP, cuando interpreta este código, da un error, al interpretar el script.

Código PHP:

<b>Strict Standards</b>:  uno and dos define the same property ($h) in the composition of prueba. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. Class was composed in <b>[...][...]</b> on line <b>11</b>
 

Ahora bien, en php, uno no está obligado a declarar las variables miembros de la clase.Hay indeseables que tienen esta costumbre.Más concretamente, yo
Si no declaramos la variable:

Código PHP:

trait uno {
    function one(){$this->h=1;}
    }
trait dos {
    function two(){$this->h=4;}
    }
 

Voilá, PHP deja de advertirnos...
Alguen huele a unas cuantas horas de depuración de código?

[GatorV]

Es lo que digo eso pasa en todos los lenguajes, realmente el programador es el que debe de estar a cargo de saber que esta implementando y como, hay muchas cosas que si, PHP te advierte, pero también uno tiene que tener cierta conciencia en lo que hace.

Como todo puede ser una herramienta de dos filos, te puede ayudar y ser una excelente herramienta, o puede ser una pistola suicida, el como se use, depende de cada uno