Estándares o muerte... para PHP

Luego de una acalorada discusión sobre el tema estándares y buenas prácticas, paso en limpio y hago un resumen de todo lo hablado, ya que veo que es un tema que los "Desarrolladores PHP" nos cuesta -aún- tomar conciencia.

Nuestros referentes obligados

Zend -la empresa- nos guste o no, debe ser siempre el referente a todo lo relacionado con PHP, ya que no solo desarrollan en la actualidad lo que puede considerarse el "Framework Oficial de PHP" (sin desmedro de ningún otro framework), también es la responsable de desarrollar el propio lenguaje PHP.

La importancia de los estándares

Los estándares nos permiten disminuir muchos costos que surgen a la hora de desarrollar sistemas que van desde la incorporación de nuevos recursos hasta el entendimiento de los sistemas "legacy" ("sistemas heredados") que existen en cualquier organización. Si todos los desarrolladores programan como quieren, o cualquiera inventa su "propio estándar" o toma el de "cualquier estándar que use otro proyecto", indudablemente esto significará caos.

Qué sucede con la empresa Sun y su lenguaje Java

Creo que está de más decir que a nadie de los profesionales que desarrolla bajo Java se le ocurriría no seguir el estándar de Sun Microsystems, y esta empresa a su vez, que es muy metódica y ordenada, tiene predefinidas especificaciones muy claras que explican cómo codificar, cómo programar, cómo usar tal o cual tecnología, para que todos los que usen la arquitectura sigan el mismo criterio.

Empresa Sun == Empresa Zend

Por lo tanto, es de sentido común tomar entonces las sugerencias de Zend como "estándar oficial" y empezar a usar sus criterios (nos gusten o no), sin importar si antes programabas estructurado en PHP con una nomenclatura y ahora quieres seguir usándola, o si no usas Zend Framework y quieres seguir el criterio de otros lenguajes.

Nota: a mi tampoco me gustó la primera vez que vi las llaves de las clases y los métodos contra el margen izquierdo, similar a C o C++, pero a las pocas semanas me acostumbré.

La Historia de PHP

PHP es un lenguaje que desde sus orígenes estuvo pensado para programar de forma estructura o "procedural" (uso de funciones y pasaje de datos a través de parámetros), pero con la evolución de los lenguajes este empezó a ser cada vez más Orientado a Objetos, tomando como referencia el lenguaje Java (en la mayoría de los casos, ya que no hizo lo mismo con el término "namespaces" que en sí lo sacan de .Net).

Aquí surge un híbrido, un lenguaje con una lista interminable de "funciones estructuradas" que empieza a evolucionar hacia los Objetos, que permite crear clases como en Java, pero que por un lado usa la nomenclatura "smallcase" (en todas sus funciones) y por otro sugiere la nomenclatura "camelcase".

"Camelcase Versus Smallcase"

"Camelcase" es un estándar en la mayoría (por no decir todos) los lenguajes POO, por lo que Zend sugiere, al igual que Java y .Net, seguir esta nomenclatura.

1  <?php
2  
3  
require_once 'Usuario.php';
4  
5  
$admin = new UsuarioAdmin();
6  
7  echo 
$admin->getNombre();
8  
9  
?>


Aquí es donde surge el problema (o la confusión), muchos desarrolladores PHP siguen usando el estándar viejo "smallcase" porque así es como inició PHP con la práctica estructurada y todas sus funciones siguen usando esa nomenclatura (ver Anexo a continuación).

1  <?php
2  
3  
require_once 'usuario.php';
4  
5  
$admin = new UsuarioAdmin();
6  
7  echo 
$admin->get_nombre();
8  
9  
?>


Pasando en limpio, para PHP la regla sería:

"Cuando es POO se usa camelcase, cuando es programación estructurada se usa smallcase"


Anexo: hacia donde debería evolucionar PHP7


Mi solución a este problema, buscando una "migración de paradigmas", sería que en PHP7 (ya que para PHP6 no hay miras de hacerlo) se implementen "Clases Wrappers" (envoltura / cáscara) que ocupen el lugar de las "Clases Base" (String, Integer, Boolean, etc) que existen en cualquier lenguaje 100% POO, logrando que cada método "esconda" la función "estructurada" correspondiente y mejorando notablemente la organización del lenguaje.

Por ejemplo, en vez de:

1  <?php
2  
3  $nombre 
'Enrique Place';
4  
5  
$cadena_en_mayusculas strtoupper$nombre );
6  
7  
?>


Debería ser:

1  
2  <?php
3  
4  $nombre 
= new String('Enrique Place');
5  
6  
$cadena_en_mayusculas $nombre->toUpper();
7  
8  
?>


Y también se debería poder hacer algo como:

1  <?php
2  
3  $cadena_en_mayusculas 
String::toUpper$nombre );
4  
5  
?>


Cuando tienes que buscar algo relacionado con "strings" solo deberías buscar los métodos dentro de la clase correspondiente.

Nota: hace algunos años había iniciado sobre este tema un proyecto experimental como parte de mi taller piloto de PHP.

En Resumen

Se sabe que Sun define todos los estándares de Java y a nadie se le ocurre no seguirlos, en nuestro caso están empezando a existir fuertes "sugerencias" de parte de Zend ("nuestra Sun") para seguir el criterio "camelcase", porque justamente, lo usan en la mayoría de los lenguajes 100% POO.

Aquí está el enlace hacia una presentación realizada por Zend sobre las Buenas Prácticas de Desarrollo en PHP y la documentación de Zend Framework donde explica el estándar de codificación del proyecto (indistintamente si usas o no este framework, la guía sirve para todo desarrollo POO bajo PHP).

Para cerrar, resumo la explicación del manual sobre el "objetivo" del estándar de codificación y una frase de la presentación de Buenas Prácticas:

"Buenas normas de codificación son importantes en cualquier proyecto de desarrollo, pero sobre todo cuando varios programadores están trabajando sobre el mismo proyecto. Usar normas de codificación ayuda a asegurar que el código es de alta calidad, tiene menos bugs, y es fácil de mantener."

"No eres tan especial como para necesitar inventar tu propio estándar"


Espero haber aportado un poco de luz sobre el tema.

20 comentarios:

Luis dijo...

Hola Enrique,

en general estoy a favor de seguir los estándares. El CamelCase me gusta y es lo que suelo utilizar, quizá porque fui formado en Java. Creo que lo importante de los estándares es más el hecho de seguir uno sea cual sea. Esto es, lo importante es NO MEZCLAR formas de escribir.

Respecto a tu idea de PHP 7, creo que te pasa como a muchos desarrolladores PHP que quieren convertir PHP en Java o en Ruby. PHP es PHP. Está claro que debe mejorar en muchas cosas, pero yo no creo que la solución sea perder todo aquello de la programación funcional y procedural que ya se sabe que funciona...

Las clases wrapper me parecen una mala idea que no encaja con la filosofía PHP. Es lo mismo que pasa con muchos frameworks MVC que hay para PHP y que copian ideas de Struts o de Hibernate. Esas cosas están bien para Java... pero no encajan con PHP. Por eso el Zend Framework es como es: diferente.

Un saludo y gracias por currarte éste post.

enrique_place dijo...

Estimado Luis:

> en general estoy a favor de
> seguir los estándares. El
> CamelCase me gusta y es lo que
> suelo utilizar, quizá porque fui
> formado en Java. Creo que lo
> importante de los estándares es
> más el hecho de seguir uno sea
> cual sea. Esto es, lo importante
> es NO MEZCLAR formas de escribir.

Todo lenguaje debe tener su estándar, la organización de Java es más estricta, la de PHP es más "suave" (aunque preferiría la primera).

Nota aparte, lo que me parece muy interesante es lo que hace el IDE de .Net, Visual Studio, ya que no se discute si sigues o no uno, porque la herramienta no te deja salirte de él, ya que luego de cada "enter" se encarga de indentarte todo el código ;-)

La primera vez que lo vi me molestó un poco, pero luego entendí la practicidad, ya que de esta forma los desarrolladores "programan muy similar".

> Respecto a tu idea de PHP 7,
> creo que te pasa como a muchos
> desarrolladores PHP que quieren
> convertir PHP en Java o en Ruby.

PHP está aprendiendo de Java, no es lo que yo digo o quiero.

> PHP es PHP. Está claro que debe
> mejorar en muchas cosas, pero yo

Son opiniones. Pero PHP como todo lenguaje, debe evolucionar, más si el paradigma predominante es la POO.

> no creo que la solución sea
> perder todo aquello de la
> programación funcional y
> procedural que ya se sabe que
> funciona...

Discrepo en este punto. Para resumir mi opinión diría que la programación procedural está "deprecated" y PHP debería pasar a ser un lenguaje 100% POO para que los desarrolladores se pongan a tono una vez por todas y no se escondan en la "flexibilidad" del mismo.

> Las clases wrapper me
> parecen una mala idea que no
> encaja con la filosofía PHP.

Lo que no encaja es que PHP permita clases como Java, pero luego no disponga de un lenguaje consistente para la misma, sin clases base y con funciones estructuradas por todos lados.

Eso genera mucha confusión.

> Es lo mismo que pasa con muchos
> frameworks MVC que hay para PHP
> y que copian ideas de Struts o
> de Hibernate. Esas cosas están
> bien para Java... pero no
> encajan con PHP. Por eso el Zend
> Framework es como es: diferente.

Discrepo también, creo que PHP debería (y así creo que lo entiende la empresa Zend) ser como Java pero más simple y pragmático, por lo cual asumo que en algún futuro lejano tendremos desde compilación, paquetes como los jars y hasta EJBs con servidor de aplicaciones.

> Un saludo y gracias por
> currarte éste post.

Gracias por compartir tu opinión ;-)

Luis dijo...

Hola enrique,

te tomas mucho esfuerzo en contestar a los comentarios. Muchas gracias.

Comentas que PHP está aprendiendo de Java. Yo no creo que sea así. Creo que el ZF ha absorvido mucho más de RoR que de Java.

Los lenguajes de scripting no creo que lleguen a estarn compilados como Java. Gracias a Dios. No sé si has probado a desplegar una aplicación struts + java en un servidor de aplicaciones Java (como jBoss)... pero para poder asegurarte de hacerlo correctamente hay que utilizar herramientas como Ant, etc. En PHP, copias los archivos por ftp y listo. El despliegue y prueba de aplicaciones es infinitamente más sencillo. Y, encima, PHP demuestra que por su arquitectura "share nothing" obtiene un mayor rendimiento a la hora de ejecutarse.

Otra cosa:¿conoces ésta herramienta?
http://pear.php.net/package/PHP_CodeSniffer/
suena prometedora. Yo todavía no la he probado.

La orientación a objetos total, como la de Ruby (no como en el caso de Java, que no está totalmente orientado a objetos) supone una gran ventaja a la hora de escribir código elegante, lo cuál es útil para aplicaciones realmente complejas. Pero para aplicaciones de tamaño medio resulta demasiado tedioso en algunos casos:se da mucho sobreuso de la orientación a objetos cuando se podría optar por opciones más sencillas y eficaces.

Un saludo!

carakan dijo...

Hola Enrique.
Tienes bastante razón en titular tu post en Estándares o muerte, y es que es así, mi punto de vista, por que PHP sigue siendo un lenguaje de programación estructurada, aunque existan INTENTOS en convertirlo a OO, tal como C, lo cual no le permite adecuarse a patrones tales como el MVC.
Antes desarrollaba en PHP, por que era facil, mas encontre en Ruby la soltura, dinamismo y la robustez que necesitaba, lo cual ahora comparo y bueno quisiera que PHP fuera igual, aunque creo que no sera así por el tema de compatibilidad hacia atrás (tanto sistemas como personas :D ).
Lastima por lo de php6 no sea el punto de inicio para mejorar el lenguaje y que des como referencia a php7.
Saludos desde Bolivia.

proclamo dijo...

Lo que me ha llamado la atención es lo de los wrappers para los tipos básicos. Si estoy de acuerdo en que todas las funciones para strings deberían ser métodos de una clase String(), pero no en cambio los constructores. En internet hay muchas discusiones sobre esto. La tendencia sobretodo en lenguajes modernos es hacia la simplicidad. ¿Qué prefieres escribir:
echo $var;
o
public int echo() {
System.out.println(var); return;
}

?

En python ni siquiera hay que usar la $:

print var

Alejo dijo...

Hola Enrique!

Desde mi opinión, el hecho que PHP sea híbrido y puedas programar en objetos, procedural, poder hacer lambdas al estilo funcional o poder hacer codigo totalmente espantoso, ofuiscado y lleno de bugs imposibles de encontrar es lo que le da el verdadero valor a PHP.

Como yo lo veo, el verdadero valor de PHP está justamente en que es DIFERENTE a Java. Hay algunos puntos débiles, pero otros que son fuertes.

Cuando decís que la programación procedural no está "deprecated" es solo una opinión o apreciación tuya. Simplemente apareció un nuevo paradigma que mucha gente lo está adoptando y en tu caso en particular te gusta bastante.

Un "Hola Mundo" en PHP es una linea de código que la tirás en un directorio y sale andando sin tener que hacer nada raro. Además, cualquier Web Hosting por más barato y de mala calidad que sea va a ofrecer soporte PHP.

Un "Hola Mundo" en Java tenés que hacer todo un gran despelote: compilar, generar el Jar, reiniciar el servidor de aplicaciones. Y si estás usando una libreria externa vas a tener que dedicarle un rato de tiempo a validar que el Classpath esté OK. Conseguir un Web Host de Java es todo un problema.

Si PHP va a tomar el mismo camino que Java, ¿por qué mejor no dejar de programar en PHP y pasar a Java?

Saludos!.

rynkydynky dijo...

que buen blog. Comparto la afición por PHP y estoy de acuerdo con lo que dices, pero entonces ¿No debería Zend sacar un libro o una web con buenas practicas para PHP como le he visto a Sun?

enrique_place dijo...

Estimado Luis:

> te tomas mucho esfuerzo en
> contestar a los comentarios.
> Muchas gracias.

Es una cuestion de respeto hacia quién lee y comenta, aunque a veces creo que pierdo el tiempo en discusiones que no llevan a ningún lado ;-)

> Comentas que PHP está
> aprendiendo de Java. Yo no creo
> que sea así. Creo que el ZF ha
> absorvido mucho más de RoR que
> de Java.

Bien, pero justamente lo que yo dije es PHP aprende de Java, no Zend Framework ;-)

> Los lenguajes de scripting
> no creo que lleguen a estarn
> compilados como Java. Gracias a
> Dios. No sé si has probado a
> desplegar una aplicación struts
> + java en un servidor de
> aplicaciones Java (como
> jBoss)... pero para poder
> asegurarte de hacerlo
> correctamente hay que utilizar
> herramientas como Ant, etc.

Como comentaba, creo que la idea y la filosofía es seguir siendo pragmáticos y ser un "Java Ágil" (por decirlo de alguna manera), adoptar algunos beneficios sin llegar a ser algo tan complejo y pesado.

> En
> PHP, copias los archivos por
> ftp y listo.

Mala práctica, sugiero transacciones por SVN conectados por SSH ;-)

> El despliegue y
> prueba de aplicaciones es
> infinitamente más sencillo. Y,
> encima, PHP demuestra que por
> su arquitectura "share nothing"
> obtiene un mayor rendimiento a
> la hora de ejecutarse.

Nadie dice que no, pero tener la opción de compilar para que no se haga una "compilación al vuelo" mejora aún más el rendimiento.

> Otra cosa:¿conoces ésta
> herramienta?

> http://pear.php.net/package
> /PHP_CodeSniffer/
> suena prometedora. Yo
> todavía no la he probado.

La tengo oída, no la he probado.

> La orientación a objetos
> total, como la de Ruby (no como
> en el caso de Java, que no está
> totalmente orientado a objetos)

¿Java no está totalmente orientado a Objetos? ¿seguro?

> supone una gran ventaja a la
> hora de escribir código
> elegante, lo cuál es útil para
> aplicaciones realmente
> complejas. Pero para
> aplicaciones de tamaño medio
> resulta demasiado tedioso en
> algunos casos:se da mucho
> sobreuso de la orientación a
> objetos cuando se podría optar
> por opciones más sencillas y
> eficaces.

Mmmm... no te entiendo cuando dices "sobreuso de objetos", eso ya es parte del diseño y no tanto del lenguaje.


> Un saludo!

Saludos!

enrique_place dijo...

Estimado Carakan:

> Tienes bastante razón en
> titular tu post en Estándares o
> muerte, y es que es así, mi
> punto de vista, por que PHP
> sigue siendo un lenguaje de
> programación estructurada,

O sea, no es 100% POO, se originó como estructurado, pero está "migrando" a POO con los últimos avances de PHP5 y PHP6.

> aunque existan INTENTOS en
> convertirlo a OO, tal como C, lo
> cual no le permite adecuarse a
> patrones tales como el MVC.

No entendí esta parte, por qué lo dices?

> Antes desarrollaba en PHP,
> por que era facil, mas encontre
> en Ruby la soltura, dinamismo y
> la robustez que necesitaba, lo
> cual ahora comparo y bueno
> quisiera que PHP fuera igual,
> aunque creo que no sera así por
> el tema de compatibilidad hacia
> atrás (tanto sistemas como
> personas :D ).

No he usado en desarrollos reales Ruby, solo lectura y pruebas. Lo de compatibilidad para atrás, si estoy de acuerdo que sucede, pero lo que no deberíamos es nosotros, las personas, "aferrarnos al pasado" y evolucionar, independientemente del lenguaje y su "contemplación con el pasado".

> Lastima por lo de php6 no
> sea el punto de inicio para
> mejorar el lenguaje y que des
> como referencia a php7.

Sí, yo me lamento que la mayoría de los cambios para por hacerlo compatible Unicode (UTF), pero bueno, es algo que se necesitaba y que les llevó mucho tiempo re-escribir todo (qué error de diseño!).

Lo que me preocupa el error "comercial" de esto, ya que si tanto trabajo dio que se aceptara PHP5, un PHP6 donde la novedad mayor es el charset (que casi nadie domina el tema) y los namespaces (que casi nadie domina el tema), dudo que sea fácil su adopción y no se espere por PHP7.

Y lo de PHP7, es lo que yo haría, no sé que van a hacer ellos. ;-)

> Saludos desde Bolivia.

Saludos!

enrique_place dijo...

Estimado proclamo:

> Lo que me ha llamado la
> atención es lo de los wrappers
> para los tipos básicos. Si estoy
> de acuerdo en que todas las
> funciones para strings deberían
> ser métodos de una clase
> String(), pero no en cambio los
> constructores. En internet hay
> muchas discusiones sobre esto.

Te parece? es algo básico de la POO, puedes o no usar un constructor para definir la inicialización de un objeto.

No veo que más se puede discutir del tema.

> La tendencia sobretodo en
> lenguajes modernos es hacia la
> simplicidad. ¿Qué prefieres
> escribir:

> echo $var;
> o
> public int echo() {
> System.out.println(var);
> return;
> }

No entiendo por qué se van tanto a los extremos, nunca dije que PHP se va a convertir exactamente en Java. ¿Tu has visto que pasó eso con PHP5? No, pero sí adoptó mejoras que fueron sacadas de la propia sintaxis de Java.

Nadie dice que va a existir un System.out.println, justamente, es la parte "mala" de Java.

> En python ni siquiera hay
> que usar la $:

> print var

Esto no es "simplificar" en sí, es parte del lenguaje.

Saludos!

enrique_place dijo...

Estimado Alejo:

> Desde mi opinión, el hecho
> que PHP sea híbrido y puedas
> programar en objetos,
> procedural, poder hacer lambdas
> al estilo funcional o poder
> hacer codigo totalmente
> espantoso, ofuiscado y lleno de
> bugs imposibles de encontrar es
> lo que le da el verdadero valor
> a PHP.

Discrepo, creo que justamente eso es lo que no nos deja evolucionar.


> Como yo lo veo, el verdadero
> valor de PHP está justamente en
> que es DIFERENTE a Java. Hay
> algunos puntos débiles, pero
> otros que son fuertes.

Opino que la flexibilidad debe ser bien entendida y que pasaría por simplificar la forma de POO de Java, pero que debería ser 100% POO.

Sobre el tipado dinámico, que sea opcional (que casi lo está siendo), poder asignar dinámicamente o poder definir tipos estrictos.

Y deberían existir las clases base y agrupadas las funciones en objetos.


> Cuando decís que la
> programación procedural no está
> "deprecated" es solo una opinión
> o apreciación tuya. Simplemente > apareció un nuevo paradigma que
> mucha gente lo está adoptando y
> en tu caso en particular te
> gusta bastante.

No es un tema personal, los lenguajes o arquitecturas predominantes hace años que solo entienden POO.

Y no se discute los beneficios de la POO sobre la forma estructurada... hace muchos años (?)


> Un "Hola Mundo" en PHP es
> una linea de código que la tirás
> en un directorio y sale andando
> sin tener que hacer nada raro.

Y un sistema hecho con esos preceptos se caen como un castillo de naipes, lo que sucede actualmente con los proyectos PHP estructurados.

> Además, cualquier Web Hosting
> por más barato y de mala calidad
> que sea va a ofrecer soporte PHP.

Entonces? (no entendí)

> Un "Hola Mundo" en Java
> tenés que hacer todo un gran
> despelote: compilar, generar el
> Jar, reiniciar el servidor de
> aplicaciones. Y si estás usando
> una libreria externa vas a tener
> que dedicarle un rato de tiempo
> a validar que el Classpath esté
> OK. Conseguir un Web Host de
> Java es todo un problema.

Creo que se van a los extremos, nunca dije que debería ser PHP exactamente igual a Java (para eso está Java). PHP, fuera de mi opinión personal, está tomando lo bueno de Java sin dejar ser PHP "el flexible".

> Si PHP va a tomar el mismo
> camino que Java, ¿por qué mejor
> no dejar de programar en PHP y
> pasar a Java?

Porque no me estás entendiendo ;-)

Poder compilar (opcionalmente), ser 100% POO y en algún futuro tener un servidor de aplicaciones, no lo hace 100% Java, es más, lo mismo lo hace .Net y estamos muy lejos de ambos.

No se olviden, PHP es solo un lenguaje, Java o .Net son arquitecturas, PHP *tiene/necesita* tener una arquitectura (guste o no), y creo que ese será su fuerte sobre las demás: simple, menos complejo, más directo.

Veamos los matices, no los extremos.

Para sobrevivir hay que evolucionar, no se puede ser tan tradicionalista.

enrique_place dijo...

Estimado rynkydynky:

> que buen blog.

Gracias ;-)

> Comparto la
> afición por PHP y estoy de
> acuerdo
> con lo que dices, pero entonces
> ¿No debería Zend sacar un libro
> o
> una web con buenas practicas
> para
> PHP como le he visto a Sun?

Debería trabajar en eso y no dejar tanto librado al azar, estoy de acuerdo.

Justamente esto es otra cosa que me gustaría que Zend imitara de Sun.

Feminologos dijo...

Hola a todos. En el articulo estoy de acuerdo con algunas cosas, con otras no. Creo PHP debería seguir siendo híbrido, la programación estructural no está "deprecated", simplemente es un modelo de programación que tiene sus ventajas y desventajas. Nadie necesita una clase para escribir "Hola Mundo" en la pantalla. Otra cosa, si PHP empieza a usar bytecode sería JPHP, obviamente esto mejora el rendimiento, pero es un fastidio andar compilando a cada momento que se modifique el código, esto es una de la cosas que me gusta de PHP, subo el archivo y al hacer la petición al servidor este me devuelve el código ejecutado, sin necesidad de hacer mas nada.

enrique_place dijo...

Estimado Feminologos:

> Hola a todos. En el articulo
> estoy de acuerdo con algunas
> cosas, con otras no. Creo PHP
> debería seguir siendo híbrido,

Muy probablemente lo siga siendo, no creo que cambie a una modalidad más estricta.

> la programación estructural no
> está "deprecated", simplemente
> es un modelo de programación que
> tiene sus ventajas y
> desventajas.

Discrepo, ningún lenguaje que sea 100% POO extraña o se siente limitado de alguna forma por la falta de la "programación estructural".

Es un tema que ya no se discute, generalmente así opinan quienes se resisten a evolucionar (no hablo en particular, hablo en general).

> Nadie necesita una clase para
> escribir "Hola Mundo" en la
> pantalla.

No, pero para hacer "sistemas" y no "páginas dinámicas" es fundamental.

> Otra cosa, si PHP empieza a usar
> bytecode sería JPHP,

No necesariamente, no tiene sentido la J de Java.

Estimo que si alguna vez existe, será opcional.

> archivo y al hacer la petición
> al servidor este me devuelve el
> código ejecutado, sin necesidad
> de hacer mas nada.

Es que justamente ese es el problema. Te es suficiente un lenguaje estructurado porque quieres hacer cosas sencillas, imprimir en pantalla o crear una página dinámica.

Los requerimientos actuales requieren diseños más sólidos, y seguir programando como hace 10 o 20 años no es un buen camino.

Ninguno, pero ninguno de los lenguajes que dominan el mercado para realizar "sistemas" se le ocurre programar sin uso de POO.

Gracias por compartir tu opinión ;-)

Feminologos dijo...

La idea de bytecode opcional sería fabulosa, pero que sea obligatoria deja mucho que desear. Yo uso POO, uso herencia, clases abstractas, polimorfismos, etc, creo que PHP orientado a objeto es lo mejor, pero eso es mi opinión, y la tuya también, pero eso no indica que todo debe ser un objeto.Hay personas que no están de acuerdo conmigo.

cuando digo esto:
> archivo y al hacer la petición
> al servidor este me devuelve el
> código ejecutado, sin necesidad
> de hacer mas nada.

No es porque no haga "sistemas", sino porque me gusta subir los archivos al servidor vía FTP, sin tener que "compilar" nada, simplemente dejar que el servidor interprete el sistema, por lo menos en la etapa de desarrollo, que hay que hacer bastantes mejoras, y seria un lío tener que compilar y subir un archivo infinitas veces hasta que le problema quede resuelto

enrique_place dijo...

Estimado Feminologos:

> creo que PHP orientado a objeto
> es lo mejor, pero eso es mi
> opinión, y la tuya también, pero
> eso no indica que todo debe ser
> un objeto.Hay personas que no
> están de acuerdo conmigo.

Mira a tu alrededor, qué se usa, sobre qué se discute.

> No es porque no haga
> "sistemas", sino porque me gusta
> subir los archivos al servidor
> vía FTP, sin tener que

Sugerencia, pasa de ftp a ssh + svn, además del versionado, tienes "deploy transaccional" en el servidor (nunca más olvidarás un archivo).

> hacer bastantes mejoras, y seria
> un lío tener que compilar y
> subir un archivo infinitas veces
> hasta que le problema quede
> resuelto

Por el momento los indicios que hay es que en algún momento exista la compilación opcional.

Nada más.

Damián dijo...

Hola. Muy Interesante el artículo. Tengo una consulta al respecto ¿Hay algún estandar en lo referente al nombre de los archivos en php con POO? En java el nombre del archivo es el mismo de la clase. O sea que si mi clase es 'Cliente', el nombre de mi archivo debería ser 'Cliente.php'
Saludos.

enrique_place dijo...

Estimado Damián:

> Hola. Muy Interesante el
> artículo. Tengo una consulta al
> respecto ¿Hay algún estandar en
> lo referente al nombre de los
> archivos en php con POO? En java
> el nombre del archivo es el
> mismo de la clase. O sea que si
> mi clase es 'Cliente', el nombre
> de mi archivo debería ser
> 'Cliente.php'

Si, es correcto.

Es un estándar que los nombres de las clases sean siempre en mayúsculas y en singular, y como en muchos otros lenguajes, la representación en archivo es igual.

Si ves Zend Framework, así está implementado y aquí una entrada en la documentación sobre Convenciones de Nombres.

Luis dijo...

Hola Enrique,

desde luego: ¡menudo éxito está teniendo tu artículo! :-D

Ésta discusión es muy interesante, pero quizá un poquito compleja para seguir a base de comentarios ...

Me centraré en una de las cosas que hemos comentado: Java como lenguaje orientado a objetos y por qué comento que no es un lenguaje "totalmente" orientado a objetos.
Lo primero porque tiene tipos primitivos: uno puede utilizar un "new Integer"... pero muchas veces se conforma con un "int i";

En el segundo caso: Java no implementa herencia múltiple. Permite implementar todas las interfaces que se quiera, pero sólo permite extender una sola clase.

Java nació cogiendo ideas de lenguajes totalmente orientados a objetos como SmallTalk y cogiendo ideas de C.
SmallTalk si es un lenguaje totalmente orientado a objetos (sin tipos primitivos y con todas las posibilidades de relación de objetos implementada como herencia múltiple, etc...) pero por esto exactamente nunca salió del ambiente académico y pasó a la empresa. Java, en cambio, supo sacrificar ciertas características algo "académicas" del SmallTalk para crear un lenguaje que pudiera adoptar todo programador.

Por cierto, que parece que PHP 5.3 va a adoptar "closures" un mecanismo superpotente que ya tiene Ruby desde siempre. Como digo: creo que PHP (y el ZF) está absorviendo muchas más ideas de Ruby (y RoR) que de Java (y Struts o Spring)...

Respecto al uso del FTP... está claro que es mucho peor que un subversion. Pero también es mucho más simple, sobre todo cuando tu base de código no es accedida por decenas de desarrolladores sino por sólo 2 o 3. Subversion me encanta... pero sólo lo utilizaría en proyectos realmente complejos (muchos desarrolladores, varias ramas, etc...). De verdad que no te puedes ni imaginar lo complicado que es desplegar una aplicación Java comparando con PHP... ¡los de java son un desastre! :-d :-D

Un saludo!

enrique_place dijo...

Estimado Luis:

> Ésta discusión es muy
> interesante, pero quizá un
> poquito compleja para seguir a
> base de comentarios ...

Cuando se vuelve un poco extensa veo de pasarla como un post nuevo resumiendo lo más interesante.

> Lo primero porque tiene
> tipos primitivos: uno puede
> utilizar un "new Integer"...
> pero muchas veces se conforma
> con un "int i";

Ahh... ok, en eso estamos de acuerdo, aunque es un detalle de Java, te permite "acortar camino" y saltearte la clase para los tipos básicos.

Luego los de Java dicen que nosotros los de PHP somos "demasiado ágiles" (chanchos) ;-)

> En el segundo caso: Java no
> implementa herencia múltiple.
> Permite implementar todas las
> interfaces que se quiera, pero
> sólo permite extender una sola
> clase.

Bueno, pero esto no es parte de ser 100% POO. No vas a ver ningún autor ni escrito de renombre que hable de diseño POO y diga que tal o cual cosa se podría hacer con "Herencia Múltiple".

Se puede concluir (siguiendo los principales autores) que la herencia múltiple está descartada y no sugerida en la POO.

Hace casi dos años tuvimos la misma discusión en Foros del Web y armé un resumen aquí y como complemento uno sobre el Principio de Liskov.

> Java nació cogiendo ideas de
> lenguajes totalmente orientados
> a objetos como SmallTalk y
> cogiendo ideas de C.

Si, de acuerdo.

> SmallTalk si es un lenguaje
> totalmente orientado a objetos
> (sin tipos primitivos y con todas
> las posibilidades de relación
> de objetos implementada
> como herencia múltiple, etc...)
> pero por esto exactamente
> nunca salió del ambiente
> académico y pasó a la empresa.
> Java, en cambio, supo sacrificar
> ciertas características algo
> "académicas" del SmallTalk
> para crear un lenguaje
> que pudiera adoptar todo
> programador.

Por esas razones no se puede tomar como referencia que SmalTalk use Herencia Múltiple.

> Por cierto, que parece que
> PHP 5.3 va a adoptar
> "closures" un mecanismo
> superpotente que ya tiene
> Ruby desde siempre.

En lo personal no estoy tan de acuerdo. Creo que es otra salida que solo puede generar más diseños desastrosos.

> Como digo: creo que PHP
> (y el ZF) está absorviendo
> muchas más ideas de
> Ruby (y RoR) que de
> Java (y Struts o Spring)...

Me parece que PHP (lenguaje) a venido tomando de Java (lenguaje) y con el tema Namespace (de VB.Net), y que particularmente Zend Framework hará cosas de Ruby On Rails hace (pero que aún no empezaron a implementar, como los scaffoldings).

> Respecto al uso del FTP...
> está claro que es mucho
> peor que un subversion.
> Pero también es mucho
> más simple,

¿Más simple que qué? Que hacer un "svn update" y que lleguen todos los fuentes, solo los modificados, sin importar si te olvidas de seleccionar uno para copiar, o si pierdes uno, que en todo momento puedes recuperar según la última versión del repositorio?

¿Más simple que un "svn update"? ;-)

> sobre todo cuando tu
> base de código no es
> accedida por decenas
> de desarrolladores
> sino por sólo 2 o 3.

Versionar es útil aún con un solo desarrollador.

Además de lo ya expuesto ¿cómo haces para mantener dos ramas de desarrollo de todo sistema? (versión desarrollo / versión producción) ¿volver atrás errores? ¿detectar cambios? ¿y si mañana traen un nuevo desarrollador?

> Subversion me encanta...
> pero sólo lo utilizaría
> en proyectos realmente
> complejos (muchos
> desarrolladores, varias
> ramas, etc...). De
> verdad que no te puedes
> ni imaginar lo complicado
> que es desplegar una
> aplicación Java
> comparando con PHP...

Si, tengo idea de algo ;-)

> ¡los de java son un
> desastre! :-d :-D

Pero estamos hablando de una arquitectura, PHP no llega ni cerca de serlo (aún).

> Un saludo!

Saludos, gracias por el aporte!

Entradas populares