PHP OO ¿__autoload dentro o fuera de la clase?

[guardarmicorreo]

Quiero comenzar a trabajar con la autocarga de clases de PHP.

Viendo los ejemplos en la doc. oficial no me ha quedado claro si a la hora de trabajar con una clase que extiende a otra la autocarga debo realizarla dentro de la clase o en una función fuera de esta. Lo explico en código.

Según la doc. oficial la autocarga puede funcionar así

Código PHP:

<?php
function __autoload($nombre_clase) {
    include $nombre_clase . '.php';
}
 
$obj  = new MiClase1();
$obj2 = new MiClase2();
?>
 

Como se ve, la autocarga está fuera de la clase.

Pero mi duda es que si tengo una clase padre y otra hija

Código PHP:

//en el archivo Padre.php
class Padre
{
 
public function comentario()
{
$hola = "Hola mundo";
return $hola;
}
 
}
 
//en el archivo Hija.php
class Hija extends Padre
{
 
var_dump($this->comentario());
//debería escribir aquí el __autoload()
 
}
 
//o mejor escribo fuera el __autoload()
 

[pateketrueke]

Esa forma es anticuada y no estándar, te sugiero usar las convenciones, lee aquí: http://phptherightway.com/

PDTA: la técnica de autoload debe ser global y śólo debe implementarse una vez antes de iniciar algo, no puedes hacerlo por método o por clase, eso sería un desperdicio.

[guardarmicorreo]

Iniciado por pateketrueke

Esa forma es anticuada y no estándar, te sugiero usar las convenciones, lee aquí: http://phptherightway.com/

PDTA: la técnica de autoload debe ser global y śólo debe implementarse una vez antes de iniciar algo, no puedes hacerlo por método o por clase, eso sería un desperdicio.

Muchas gracias! :)

Pero ¿Dónde dice algo de la convención para autoload?

No lo encuentro :S

[pateketrueke]

Lee la parte que habla de Composer y el PSR-0.

[guardarmicorreo]

Iniciado por pateketrueke

Lee la parte que habla de Composer y el PSR-0.

Entonces ¿la convención es utilizar Composer o PEAR? :S

Nunca había escuchado de PEAR, de Composer sí.

[pateketrueke]

PEAR se diseño hace tiempo, cuando aún no se tenían versiones de PHP maduras como ahora.

Composer nació a raíz de actualizar dicha forma de manejar dependencias, es la convención moderna por decir algo.

[dashtrash]

Mmm..Yo no diría que __autoload está anticuado.Lo que sí hay que tener es cuidado con él, y con qué se hace dentro.Si se pasa un profiler (valgrind) a muchos de las "aplicaciones prefabricadas" y frameworks, se ve que entre las primeras posiciones de las llamadas que más tiempo han costado, están llamadas a is_file o file_exists que provienen de los autoloaders.

Con respecto a las librerías/utilidades que indica pateketrueke, hay algo que está implícito en esas herramientas, y que es interesante.Y es que el código escrito por el programador, a través de herramientas, es analizado y modificado.PHP tiene una larga tradición de que el código que escribes, es el que se ejecuta.Esto no tiene por qué ser así.El uso de __autoload permite que, aunque escribas código donde cada clase es un fichero, está todo estructurado como es óptimo a la hora de escribir código, a través de herramientas, lo transformes en una estructura que es óptima para ser ejecutada en un servidor web (y no coincide para nada con la primera).El uso de __autoload (aunque hay otras estrategias) permitiría ocultar cómo se cargan las clases.
Así podrías tener , a la hora de desarrollar, cada clase en su propio fichero.Ejecutas un comando , y "paquetizas" el código para su ejecución en el servidor, haciendo que, por ejemplo, varias, muchas o todas las clases acaben en 1 solo fichero que es siempre incluído.

[guardarmicorreo]

No es que no me gusten las herramientas ajenas a PHP o al lenguaje en el que estoy programando, simplemente no veo necesario hacer con una herramienta externa algo que debería hacer en si mismo el propio lenguaje. Sino sería como estar trabajando con photoshop y de repente utilizar un generador automático de iconos e insignias, se ve realmente vago.

Por otro lado me gusta, hasta cierto punto, controlar lo que programo, disfruto que lo que pongo a funcionar lo haya escrito yo como resultado de mi, escaso :D, ingenio.

Por eso, Composer no quiero utilizarlo, aún a riesgo de saltarme, las tan necesarias, convenciones.

__autoload() lo veo como una herramienta excepcional y considero que si ha quedado en lo anticuado (cosa que no sabía hasta hoy), es porque no se ha sabido aprovechar su potencial, tampoco es que pueda hablar en general, pero mi primera impresión es esa.

Mi necesidad de comenzar a trabajar con __autoload() es porque he comenzado a replantear una app de manera que todo lo que pueda plasmar en clases ¿para qué tenerlo en funciones?

Ese replanteamiento me ha llevado a cambiar mi práctica de escribir todo en una o dos clases a escribir una clase por cada cosa que voy y vaya necesitando.

Esto a su vez me ha llevado, inevitablemente, a querer encontrar una forma fácil de cargar las clases padres y otros de forma dinámica, ahí me encontré con __autoload()

Ahora que os leo, estoy en un abismo de dudas, cuestiones y sinceramente, la tendencia que me comentais que se produce al establecer por convención utilizar PEAR o Composer, no me gusta.

He pensado en utilizar __autoload() de manera que vaya buscando en cada carpeta partiendo desde la raíz del servidor el archivo .php que se llama igual que la clase.

Todo esto lo digo desde la absoluta ignorancia de saber cómo funciona exactamente Composer, pero mi impresión y reacción por lo pronto es esa

¿para qué utilizar algo ajeno al lenguaje? porque en ese caso es como evidenciar que PHP es un lenguaje realmente pobre en algunos aspectos y creo recordar que en otros lenguajes, como java, este tipo de problemas no sucede, por lo menos lo poco que recuerdo de mi iniciación en java y del que apenas se mucho.

¿Veis mi idea factible desde un punto de vista economista en recursos de procesamiento y universalidad? Porque, este __autoload sería una función en un documento y solo tendría que ir escribiendo en los otros documentos la inclusión a esta función y terminado.

En el caso de que necesitara __autoload() dentro de una clase entonces simplemente creo la clase autoload y la utilizo.

¿Qué os parece?

¿A qué otras estrategias te refieres dashtrash?

[pateketrueke]

Todo eso que acabas de mencionar ya esta resuelto por medio de convenciones y estándares, si no quieres hacer caso de ninguno entonces te toca inventar en hilo negro por ti mismo.

El estándar PSR-0 es exactamente el mismo que establece como definir y emplear las diferentes estrategias de autoload, te sugiero leer bien antes de hacer afirmaciones poco fundamentadas.

Composer tampoco es ajeno a PHP, está escrito con PHP para ser usado en PHP.

Composer es una herramienta para gestión de dependencias, si te informas mejor descubrirás que la técnica de autoload apenas es la punta del iceberg, y por supuesto no estás obligado a usar el 100% de las reglas.

Que los árboles no te impidan ver el bosque.

[dashtrash]

Iniciado por guardarmicorreo

He pensado en utilizar __autoload() de manera que vaya buscando en cada carpeta partiendo desde la raíz del servidor el archivo .php que se llama igual que la clase.

Esa no es una excelente idea...Como decía en mi primer post, abrir ficheros PHP del disco es una operación muy costosa.Mucho más aún si los "buscas".
Una sugerencia: utiliza namespaces.Cuando vayas a crear una clase, según el namespace que le llegue al autoloader, debería saber exactamente el path del fichero a abrir.Pero..."buscarlo en cada carpeta"...De verdad, no quieres hacer eso.

Iniciado por guardarmicorreo

¿para qué utilizar algo ajeno al lenguaje? [...] creo recordar que en otros lenguajes, como java, este tipo de problemas no sucede, por lo menos lo poco que recuerdo de mi iniciación en java y del que apenas se mucho.

En lenguajes donde hay una fase de compilación , y otra de "linkado", las referencias externas tienen que estar resueltas en el linkado.Y, desde luego, a Java, en tiempo de compilación/linkado, tienes que indicarle la localización de todas las dependencias externas (el equivalente a "include").
En Java (C,C++,C#,etc,etc) , en tiempo de ejecución, no se usa el código que has escrito, con la estructura de ficheros que le diste.Puedes ejecutar el programa sin el código fuente.En PHP, y lenguajes interpretados del mismo tipo, no.En tiempo de ejecución, se requiere el mismo fichero que editas, y que tienes que mantener.
Eso le permite a PHP que, para hacer un cambio, modificas el fichero, recargas la página, y listo.Eso no lo puedes hacer en Java.Tienes que pasar antes por las fases de compilación y "linkado".

Iniciado por guardarmicorreo

¿Veis mi idea factible desde un punto de vista economista en recursos de procesamiento y universalidad?

Tal cual, no.Si haces un profiling del sistema, verás cuánto consume "buscar" el fichero php desde el autoloader.

Iniciado por guardarmicorreo

¿A qué otras estrategias te refieres dashtrash?

Hay muchas, pero depende de cómo estructures tu desarrollo.Una rápida, que puedes comprobar, es lo que hace..creo que es...prestashop 1.5.
Lo que hace es mantener un fichero caché donde está cada clase, y qué fichero la contiene.El mantenimiento de esta caché se hace en tiempo de ejecución: se carga la caché (un array), y si no se encuentra la clase, entonces se busca.
Esto lo hace así, ya que prestashop te permite sobreescribir cualquier clase de su "core" (sean modelos o controladores).Por lo tanto, por cada modelo o controlador que quisiera cargar, su autoloader debería mirar primero si esa clase está sobreescrita por el usuario.Fíjate que en este caso, sólo se hace 1 is_file() (sobre la posible clase sobreescrita por el usuario).Eso ya ralentiza lo suficiente como para que prestashop mantenga una caché.

[dashtrash]

Iniciado por pateketrueke

Composer es una herramienta para gestión de dependencias

Pero, por lo que veo, es para gestionar dependencias "externas" (librerías, frameworks...)..
No está mal, para quien se "arriesgue" a ello..Personalmente, prefiero meter mis dependencias en git...Y saber exactamente qué versión de qué, tengo en el proyecto..
Pero, por lo que leo (si no me equivoco), Composer no va a ayudarte para hacer autoload de la clase correcta en casos del tipo:

Código PHP:

$a = new $b();
 

Que yo sepa, ese es el problema que debe resolver __autoload...Cuando menciona "autoload" de dependencias en el link que has dado, no sé si se refiere a lo mismo.

[pateketrueke]

dashtrash, si buscas aquí verás que todas las dependencias están en un repositorio público, todas están enlazadas a un repositorio Git (o compatible).

Definitivamente también te ayuda a resolver temas de versiones usando semver (semantic versioning) lo cual es un estándar en casi todo proyecto de software.

El autoload lo resuelve, no sería una solución viable si no fuera nada de lo mencionado anteriormente, además que usando namespaces como mencionas se obtiene resultados mas robustos y eficientes.

Composer es la herramienta de facto para gestionar dependencias externas o internas de un proyecto en PHP, así como podría ser Bundler para Ruby, Bower para Javascript (client-side) o NPM (nodejs), etc.

[dashtrash]

A mi entender, eso es PEAR con unas reglas simples de creación de namespaces (por cierto, que poner a primer nivel el nombre de los vendors, es lo que en js se llama "polluting the global namespace", con cosas como "Zend", "Symfony",etc,etc...).
Cuando sabes qué clase quieres cargar, y el autoload es simplemente cuestión de ahorrarte el include, con las reglas indicadas en PSR-0 es bastante.
Pero hay casos de autoload más complejos (hace poco: clases base que dependen del dominio desde el que se carga una página , clases derivadas que no..) que creo que no encajan dentro de esa estructura.
Por otro lado, el namespace global yo lo uso principalmente para cosas relacionadas con objetos de negocio de mi sistema.Un ejemplo sería: Backoffice\Almacen\Caja. Según PSR-0, esa clase debería llamarse Backoffice\objects\Almacen\objects\private\Caja... .

[pateketrueke]

Según PSR-0, esa clase debería llamarse Backoffice\objects\Almacen\objects\private\Caja...

No, eso no está definido en dicho estańdar, me parece que te refieres a esto:

vendor/Backoffice/Almacen/Caja.php

Código PHP:

namespace Backoffice\Almacen;
 
class Caja {}
 

script.php

Código PHP:

require 'vendor/autoload.php';
 
use Backoffice\Almacen\Caja;
 
$foo = new Caja();
 

Al caso debo mencionar que todavía no he visto un ejemplo complejo de dependencias (de clases obviamente) que no se pueda resolver usando PSR-0 (autoload), si tienes alguno sería interesante revisarlo.

[dashtrash]

Iniciado por pateketrueke

No, eso no está definido en dicho estańdar,

Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system.

Si el path de mi fichero es Backoffice/objects/Almacen/objects/private/Caja, su namespace debería ser ese.
Y que el path del fichero sea ese, no es casual.Backoffice tiene más cosas que objetos (configuraciones, caches,etc).Almacen tiene más cosas que objetos (vistas, controladores, datasources,generadores,etc).
Mi código es mucho más legible escribiendo Backoffice\Almacen\Caja. El hacer que los namespaces coincidan con los paths no siempre ayuda.

Iniciado por pateketrueke

Al caso debo mencionar que todavía no he visto un ejemplo complejo de dependencias (de clases obviamente) que no se pueda resolver usando PSR-0 (autoload), si tienes alguno sería interesante revisarlo.

En general, cualquier sistema basado en "plugins".
En particular, un sistema donde quieras, por ejemplo, que un usuario pueda sobreescribir un controlador (el ejemplo que daba antes de prestashop).
Una forma sencilla de hacerlo:

Controlador base:

Código PHP:

namespace base\Controllers;
class MyController
{
    function a(){ echo "BASE";}
}
 

Controlador sobreescrito por el usuario:

Código PHP:

namespace user\Controllers;
class MyController extends \base\Controllers;
{
    function a(){ echo "USER"; }
}
 

Instanciación del controlador:

Código PHP:

$controller=new \run\MyController();
 

No existe ninguna clase "run\MyController", ni directorio "run".Pero, examinando el namespace pedido, el autoloader puede comprobar si existe user\MyController, y si no, devolver base\MyController.

Variaciones de este caso de uso existe en casi cualquier "aplicación prefabricada".

[pateketrueke]

Ah, ya entiendo, tienes una estructura de archivos que no es compatible con PSR-0.

Es bueno el ejemplo de los pre-fabricados, pero como sea, se sale del tema de autoload y PSR-0 pues su objetivo no es resolver todos los problemas derivados con dependencias de terceros.

Edito: cambiando de tema, ¿tu sugieres emplear PSR-0 o implementar un autoload a medida?

[dashtrash]

No los veo como cosas incompatibles, porque creo que su objetivo no es exactamente el mismo. Mientras PSR-0 lo veo más como una resolución de dependencias "en tiempo de codificación" (bajar la versión correcta de un paquete, dado tu entorno de desarrollo), yo veo __autoload como resolución en tiempo de ejecución.
Aun así, tanto una cosa como otra lleva a que los proyectos estén muy fragmentados en ficheros.Y eso es muy costoso en tiempo de ejecución (casi cualquier cosa que use un framework o aplicación "prefabricada", no es raro que cargue 70/100 ficheros).
En el fondo, lo que el servidor web quisiera, la caché de opcodes (APC,etc), la caché de disco quisiera, es que una página requiriera 1 solo php (cómo conseguir esto, o algo cercano, pero mantener el código fuente "fragmentado"?)
Cosas como "buscar la clase" en el autoloader.....no es una buena idea.

[pateketrueke]

¿Ya miraste esto?

https://github.com/php-fig/fig-stand...epted/PSR-0.md

Todo es en tiempo de ejecución.

[dashtrash]

Si, claro, a ver, a lo que me refiero, es que a la hora de codificar, sabes qué clase quieres cargar.A eso me refería con resolución de dependencias "en tiempo de codificación", aunque sería más exacto decir "determinar la dependencia".En los casos de uso anteriores, la dependencia no se puede determinar a la hora de codificar.

[guardarmicorreo]

Me gustó mucho la conversación que tuvieron, voy a informarme más sobre composer, PSR-0 y namespace a ver qué saco en claro y útil. Pero sin duda gracias a los dos! :D

[guardarmicorreo]

Creo que voy entendiendo todo esto. Pero tengo una duda

¿Cómo interactuan __autoload() y namespace de manera que cumpla con con PSR-0?

Lo que entendí hasta el momento fue lo siguiente.

En PHP hay varias maneras de incluir un archivo en otro (include, include_once, require y require_once).

A la hora de escribir código bajo el paradigma POO los programadores nos encontramos con la problemática de que escribimos una clase por cada archivo y a la hora de hacer que interactuen entre ellas debemos escribir una larga lista de inclusiones dentro de unos archivos u otros según necesitemos más o menos clases.

Por otro lado, a mayor número de clases, mayor es la posibilidad de que dos clases o métodos se llamen iguales. Escribir un largo nombre por cada archivo, clase y método no es factible y es semánticamente horrible.

Para solucionar esto hay dos herramientas que interactuan entre ellas, aportando una manera sencilla y eficaz de poder incluir unos archivos en otros y poder utilizar unas clases u otras.

Estas herramientas son

-La autocarga de clases, __autoload().

-Los namespaces.

autoload de PHP a partir de la versión 5.3 funciona tal que así

Código PHP:

function __autoload($clase)
{
include ($clase.'.php');
}
 
//una forma más elaborada sería nombrar la clase Archivo_Clase
//y en el autoload
 
function __autoload($clase)
{
$ruta = str_replace('_', '/', $clase);  
require_once  $ruta . '.php';  
}
 

namespace de php se utiliza así.


Pero todavía no entiendo cómo interactuan estas dos herramientas.

[pateketrueke]

Lee esto: https://github.com/php-fig/fig-stand...epted/PSR-0.md

Y en dado caso es lo mismo que esto:

Código PHP:

echo str_replace('_', '/', 'Foo_Bar');
echo str_replace('\\', '/', 'Foo\\Bar'); // namespaces
 

[guardarmicorreo]

Estoy haciendo pruebas en local (XAMPP). Tengo el siguiente código

en el directorio raíz:

en el directorio models
prueba1.php

Código PHP:

<?php
 
namespace models;
 
class prueba1
{
    public function hola()
    {
        $hola = "hola";
        
        return $hola;
    }
}
 
?>
 

en el directorio raíz:

en el directorio models2
prueba2.php

Código PHP:

<?php
namespace models2;
function __autoload($class)
{
    $class = str_replace('_', '/', $class);
    require_once  $class . '.php';  
}
 
class prueba2
{
    public function resultado()
    {
        $nclas  = new models/prueba1();
        $hola   = $nclas->hola();
    
        return $hola;
    }
}
 
$nclas = new prueba2();
 
var_dump($nclas->resultado());
?>
 

me da este error :S

Fatal error: Class 'models2\models' not found in C:\xampp\htdocs\xampp\web\models2\prueba2.php on line 13

No entiendo por qué me dice "models2\models" si la clase models no existe, solo directorio.

¿Alguien puede ayudarme?

[pateketrueke]

Antes de seguir intentando la técnica de autoload te sugiero estudiar bien como funcionan los namespaces.

El error que obtienes se debe a que ya estás en otro namespace, y si no especificas la barra invertida inicial entonces se comienza a buscar en el namespace actual.

Código PHP:

namespace models2;
 
// MAL
new models\prueba1();
 
// BIEN
new \models\prueba1();
 

Al colocar la barra invertida inicial se le dice a php "hey, no busques desde aquí, por favor busca desde el namespace global".

Por favor, consulta el manual.