PHP 7.4: qué podemos esperar de este nuevo release que se viene en noviembre

Insertar un subtítulo acá mismo.


Hace muchos años pienso por dentro:


«Che … ¿No será que PHP se parece cada vez mas a JAVA?»


Inevitablemente, se quiera o no, JAVA marcó el camino como el lenguaje a seguir en Programación Orientada a Objetos. Podemos decir que es un lenguaje el cual requiere de una gran capacidad de procesamiento, y SÍ, indudablemente lo es. Otros podrán decir (o discutir) de que no se está usando correctamente cuando un programa hecho en JAVA es deficiente respecto al trato de la memoria.


Related image

Lo que no podemos discutir es que la sintaxis de JAVA ha servido de inspiración para lenguajes como PHP, Ruby o Javascript. Y no me cabe duda alguna de que esta es excelente (fans de lenguajes funcionales como Haskell o ErLang, abstenerse). Tal es así que uno de los features de PHP 7.4 serán las propiedades tipadas.


Pero, ¿cómo dice usted señor Stange?


Así es, finalmente el core team de PHP se ha decidido por utilizar propiedades tipadas.


RFC creado por Bob Weinand y Nickita Popov (Basado en un RFC previo realizado por Joe Watkins y Phil Sturgeon).


Nota: ¡Si! Nikita Popov es el muchacho que creó nikic fastroute.


Éste, nos plantea la posibilidad de tener propiedades tipadas en PHP, algo lo cual en Java se toma como natural. Sin embargo, los programadores que siempre han apostado 100% a PHP, encontrarán este feature como algo innovador.


Nota: he mencionado a todos los autores ya que la comunidad de PHP es muy … digamos … «indecisa» ( no quiero agregar adjetivos calificativos negativos) respecto a ciertas cosas. Y cuando algunas personas han sido visionarias en su momento, las han tratado de estúpidas.


Bien podríamos decir de que el síndrome de Tesla es frecuente dentro de esta comunidad. O bien uno podría unirse a cierto medio de comunicación antiguo llamado IRC (en cierto servidor llamado freenode) y comprobarlo por si mismo.


Como mencioné al principio del artículo, esta evolución del lenguaje es 100% natural y la inspiración claramente es JAVA.


Vas a ver que muchas veces hablo de JAVA, pero sin embargo, puedo asegurarte de que no es mi lenguaje de preferencia. Pero una cosa no quita la otra. Te lo pongo más claro, no me gusta el pop, prefiero el metal, pero Madonna la rompe.»


Podemos ver esto simplemente viendo a la versión 7 de PHP:

class Test {
public function setSomeClass(SomeClass $class, int $someNumber){
}
}

Ya desde la version 5 teníamos type hints de clases e interfaces, callable y de arrays. Claramente, desde este momento se podía divisar hacia adónde apuntaba la evolución del lenguaje.


Tal es así que en la versión 7 comenzamos a ver «type hints» … o bien «declarations» (como los llamamos ahora en PHP 7) de tipos «scalar», a saber, int, array, string, float, bool, double, como tampoco otros … iterable (PHP 7.1.0) u object (PHP 7.2.0).


Es solamente una natural evolución, que el lenguaje incorpore atributos de clase tipados al igual que JAVA.


Como también, ¡comenzamos a ver «Return types» en PHP 7!:

class Test{

public function test() : string
{
return ‘hello world’;
}

public function getSomeClass() : SomeClass
{
return $this-someClass;
}
}


¿Qué quiere decir que vamos a tener atributos/propiedades de clases tipados en PHP 7.4?

No hay nada mejor que una porción de código para demostrarte esto:


class Test{
private UserModelInterface $user;
private MyClassInterface $class;
}


Si esto es así … ¡¿Donde quedaron mis amigos setters y getters tipados?!


Ejemplo:

class SomeClass {

/**
*@var UserModelInterface
*/
private $userModel;

public function setUserModel(UserModelInterface $userModel)
{
$this->userModel = $userModel;
}

}


Y la respuesta es… siempre es bueno tener setters y getters, en caso de que la clase decida realizar otras operaciones / comparaciones adicionales antes de setear una propiedad acorde a la lógica de dominio.


¿Un ejemplo de esto?


Una clase puede decir: «No podés setearme un usuario si el usuario no tiene un nombre y un apellido» (caso claro en el cual arrojaríamos una excepción).


SIEMPRE … SIEMPRE, mediante un método vas a tener mayor control en un dominio específico de una clase que mediante una propiedad.


Podemos dar un ejemplo pedagógico de la vida real … pensalo de esta manera, la clase siempre es el contexto de nuestro dominio.


El ejemplo es el siguiente:

  • Está perfecto quitarme la ropa para ir a bañarme
  • No es éticamente correcto quitarme la ropa y salir a la calle

class PersonaService{
public function pegarseUnaDucha(PersonaModelInterface $persona)
{
if($persona->estaVestido()){

throw new exception\DebeQuitarseLaRopaException(‘Por favor desvistase primero’);

}

echo «Canto alguna canción berreta mientras me baño … lalalalala\n»;
}

public function salirDeCasa(PersonaModelInterface $persona)
{
if(false === $persona->estaVestido()){
throw new exception\VasEnCanaException(‘Hans Reiser, un poroto’);
}

echo «Un bello dia de sol … ponele …\n»;

}
}


Sin las validaciones de los métodos, ¿podríamos imaginar lo que hubiese pasado, creo … ?


NOTA: algunas personas prefieren setear y luego posteriormente al momento de salvar una entidad, realizar la validación correspondiente. Sin embargo, al validar al momento de setear una propiedad, se gana tiempo de ejecución ya que, de haber algún error, no debe esperarse al momento de guardar una entidad, sino que, la aplicación arroja el error al instante en el cual el error se produce. Ambas posiciones son válidas, dependiendo de cada implementación como desee manejarlo.


Otro ejemplo:

class Test{
private UserModelInterface $user;
private MyClassInterface $class;

public function setUser(UserModelInterface $user)
{

if($user->getName === »){ throw new \LogicException(‘Usuario no puede tener nombre vacio’); } $this->user = $user;

}

/**

Ojo al piojo, segun el RFC de PHP 7.4, $this->user puede NO estar inicializado, caso en el cual declarariamos dicha propiedad como private ?UserModelInterface (NOTESE EL SIGNO DE PREGUNTA).
*

Y aquí diríamos como return type: ?UserModelInterface para asegurarnos de que algo siempre este inicializado o no, ponerlo en

nuestro __construct como parametro requerido 🙂
*/ public function getUser() : UserModelInterface
{
return $this->user;
}

}


PHP 7.4 se ve muy prometedor, y pavimenta el camino hacia métodos, los cuales indiquen que excepción arrojarán (¡El famoso throws exception!), así también como otros features los cuales estamos acostumbrados a ver en lenguajes como JAVA (alguien dijo collections?).


¡Espero que te haya gustado el articulo! ¡Te mando un abrazo gigante y espero verte pronto por Educación IT!


Federico Stange

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.