[PHP 6 Namespaces] Una mala implementación

En las primeras de cambio, cuando aquel ruso Dimitri (Dmitri Vinogradov) postuló el parche para soporte de namespaces en php5 ó 6 y se inició un rally para incorporarlos rápidamente al lenguaje; mucha gente se entusiasmó, pensando que por fín se acabaría la cadena (o el yugo) a los nombres de función crípticos y a las implementaciones de 40 mil includes y requires al inicio de un archivo.

El preámbulo

Inicialmente el parche prometía bastante; al implementar un sistema de espacio de nombres basado en filesystem (y con soporte y resolución dinámica) muy semejante al de python:

<?php
namespace Proyecto::DNS;
class resolver {
public function get($ptr) {
}
}
?>

Y su implementación se realizaba:

<?php
use Proyecto::DNS as dns;
dns->get('127.0.0.1');
?>

Lo cual por legibilidad es más o menos como usar:

import DNS
DNS.get('127.0.0.1')

Lo cual parecía ser la solución “idónea” a los problemas de resolución del lenguaje; sin embargo, en octubre del 2008 la gente del buró de decisiones de Zend (la empresa que lleva el lenguaje PHP); decidió, fuera de toda lógica plausible; tratar a los espacios de nombres y a las clases como dos cosas completamente distintas; de tal manera que la resolución de nombres usando el :: quedaba descartada del lenguaje.

El problema

En la mayoría de los lenguajes no encontrarás una clase llamada igual que un namespace (o package como en Java o módulo como en python); o sea, nunca verás algo como:

import org.java.lang

donde Java.lang pueda ser un package y además una función; los increíbles de PHP desean hacer eso; con lo cual sentenciaron el separador (::) a muerte (al menos como separador de los namespaces, ya que el punto (como en python o java) no se puede usar porque es el concatenador lógico)).

Según la gente de Zend; tener:

<?php
namespace Proyecto;
function DNS() {}
?>

y

<?php
class Proyecto {
public function DNS() {
}
}
?>

Es sintáctica y además lógicamente válido;  lo que conlleva a que:

<?php
Proyecto::DNS();
?>

No sepa determinar si nos referimos a la función DNS en el namespace Proyecto o al método DNS en la clase Proyecto, llevando a confusiones al motor Zend2; obviamente, esto conllevó a una decisión.

La fatídica solución (Según Zend)

Lo que la gente de Zend ha ideado; es obviamente un disparate; como según ellos lo anterior “se puede hacer” (aunque no se debería tener un namespace y una clase con el mismo nombre), entonces debemos “adoptar” el slash (o separador Windows “\”, que se alegren los programadores .NET) como separador de las resoluciones de nombre; de tal manera que lo de arriba queda así:

<?php
Proyecto::DNS(); //llamando estáticamente al método DNS de la clase Proyecto
\Proyecto\DNS(); //llamando a la función DNS del namespace proyecto
?>

¿Que rayos es esa cosa?; otra horrible invención de Zeev Zurasky y pandilla!; esto hará que:

<?php
\Date\time(); //namespace Date, función time()
Date::time(); //clase incorporada Date, método time()
?>

Es decir, a la clase Date (incorporada en PHP5.1) puedo crear paralelamente un namespace Date con una función llamada idénticamente a su contraparte de la clase; no hay nada más horrible que esto.

¿No era más sensato, como en otros lenguajes, evitar que un package y una clase compartieran el mismo nombre?.

Las ventajas (que no lo son tanto)

He decidio copiar y desmentir cada una de las “ventajas” que han puesto para aceptar el cambio del separador.

  • name ambiguity is impossible
¿Qué es más ambiguo?, que se “lean” diferente o que pueda existir un Namespace y una clase con el mismo nombre?; imaginen esto:
<?php
\com\Zend\Data\Form::validate();
\com\Zend\Data\Form\validate();
?>
Ambas formas en el mismo script!, sintáctica y logicamente válidas; pero a la vista, ambiguas ambas (y un completo disparate).

  • \ is visually quite different from ::, and is easier to scan and detect as namespace instead of static class operator

Creo que la presencia de un import (o USE en PHP) es una facil forma de detectar “visualmente” quien es un namespace y a quien nos referíamos estáticamente.

  • \ is a single keystroke on U.S. keyboard layout without shift key

En la mayoría de los teclados latinoamericanos y españoles es imposible obtener el \ a la primera, a veces uno ni lo consigue!.

  • \this\is\used for paths on Windows and is intuitively familiar to those developers. According to a php|arch survey (as relayed by Steph Fox), most of their readers develop on Windows and deploy on Unix, which would imply that \these\paths are familiar

… Sin comentarios; recordemos que ahora Microsoft le apuesta a los lenguajes de scripting libres (python, php) en vez de a su .NET, así que tiene una fuerte inversión con Zend.

  • \this\maps\to\filesystem layouts often used by autoload intuitively for the above reason

Pudieron haber escogido el backslash de unix igualmente, o el punto, para parecerse más a otros lenguajes “serios” (ruby, phyton) …

  • because \ is a single keystroke, it is possible to require \ prefix for all global functions/classes/constants, and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)
El “namespace” global requerirá que “escapemos” todas las funciones y constantes globales, de tal manera que tendremos que llenar el código con cosas como:
<?php
\htmlspecialchars($variable);
?>
Simplemente hilarante.
  • code review ambiguities disappear permanently
Y muchos programadores enojados desaparecerán también permanentemente.
El Análisis posterior
Este parche ha sido incorporado a PHP 5.3; pero aún los cambios no han sido incorporados a PHP6; muchos vaticinan que ocurrirá algo parecido a la actual página http://www.gophp5.org (un gophp6.org) en un tiempo no mayor de 3 años; como consecuencia de que “proyectos de PHP4 no correrán en > PHP 5.3”; pero además, código escrito en PHP 5.3 o superior posiblemente no corra en PHP6.
Esto hace además que guias como esta; publicadas antes del parche de noviembre del 2008, sean inválidas, dicho sea de paso, hasta el .chm oficial en español de la documentación de PHP está erroneo pues no ha incorporado los cambios.

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 4 febrero 2009 en Blogeando!, Cultura Libre, PHP, PlanetaLinux, Programacion y etiquetado en , , , , , . Guarda el enlace permanente. 2 comentarios.

  1. Que mierda es Zend tiene un malvado monopolio con el desarrollo de PHP, esto lo que provoca es tirar la toalla, seguramente ya Zend Framework estará muy adelantado respecto a estas adecuaciones de namespaces, lo que se me viene a la mente a parte de las gafedades como la que comentas en el post, es que Zend quiere ser el “Rey” de los framework…

  2. Si CaChi; el Zend Framework y su sistema de paquetes basado en filesystem es el más beneficiado por la aprobación de la reciente modificación del sistema de Namespaces; yo hace algún tiempo me hice un framework PHP5 (fork de CodeIgniter que es php4/php5) y no veo con buenos ojos migrarlo a PHP6 en vista de la forma como se implementará el sistema de Packages.
    Pos no será tanto “tirar la toalla”, pero será volver a la época de PHP4/PHP5 donde habrá gente que no querrá migrar debido a los cambios incorporados al lenguaje.
    Posiblemente veremos un repunte en el uso de Django y RoR como frameworks de desarrollo entre la comunidad de programadores de PHP.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: