Por qué molestarse con la carga automática en WordPress, Parte 2
En la publicación anterior, cubrí algunos puntos sobre por qué creo que include_once, require_once y otras declaraciones similares dan como resultado prácticas de desarrollo deficientes (al menos en lo que respecta al trabajo que estamos haciendo con nuestros proyectos de WordPress ).
Si no lo has leído, no es gran cosa. La esencia de la publicación es que estas declaraciones hacen:
- depuración más difícil,
- rastrear el código es más difícil de hacer.
En última instancia, son cosas que podemos evitar. Termino el post con lo siguiente:
Esto aún deja la pregunta de por qué se necesita la carga automática (o cualquier inclusión de archivos de terceros).
Y aunque me encantaría cubrir todos los detalles en esta publicación, tomaré esta y una publicación más como importante para comprender algunos temas fundamentales sobre lenguajes, intérpretes y compiladores antes de avanzar demasiado.
Autocarga en WordPress: Tipos de Idiomas
Cuando se trata de lenguajes de programación, se pueden dividir en dos tipos distintos de lenguajes:
- tipificado estáticamente
- tipado dinámicamente
También son fáciles de detectar.
Lenguajes de tipo estático
Un lenguaje de tipo estático significa que cuando declara una variable, como una cadena, un número entero o un número de coma flotante, mantiene ese tipo durante toda su vida útil.
Esto no significa que no se pueda cambiar o analizar en otro tipo, pero la idea es que declares su tipo y así es como funciona.
Por lo general, se especifica como un cierto tipo cuando se declara, como string o int, y se ve con mayor frecuencia en lenguajes compilados.
Lenguajes de tipado dinámico
Los lenguajes tipificados dinámicamente, por otro lado, tienen variables que son más fluidas, a falta de un término mejor, en la naturaleza.
Es decir, inicialmente puede declararlo como una cadena, luego compararlo con un número entero y luego usarlo como una cadena nuevamente.
El intérprete o compilador (según el idioma que esté usando) hará lo mejor que pueda para inferir lo que está tratando de hacer en función del contexto de lo que está haciendo en su código, pero no siempre es correcto.
Eso puede conducir a efectos secundarios extraños y errores.
JavaScript es así. Para ver un ejemplo, abre la consola de tu navegador e ingresa algo como lo que ves en la siguiente captura de pantalla (y presta atención al resultado):
Tenga en cuenta que cuando usamos un signo de igual doble estándar, el intérprete fuerza la cadena al tipo booleano aunque la cadena verdadera no sea verdadera.
El segundo caso es exacto (y es por eso que casi siempre se deben usar triples iguales).
Además, cómo algo puede funcionar en un idioma no es cómo puede funcionar en otro idioma.
La conclusión es que no espere que sus idiomas hagan lo mismo solo porque pueden admitir escritura dinámica.
¿Qué tiene que ver esto con la carga automática?
De acuerdo, hemos hablado un poco sobre las primitivas y todo eso está bien, pero no hace mucho cuando se habla de clases, objetos, creación de instancias, carga automática, etc., ¿verdad?
El propósito de traer a colación los temas antes mencionados es mostrar el rol que juegan los intérpretes y compiladores cuando se trabaja con código en lenguajes dinámicos.
Y esto es importante porque PHP es un lenguaje dinámico.
En este punto, originalmente iba a comenzar a ver el código PHP de muestra, los espacios de nombres, la carga automática, las declaraciones de inclusión y todo eso, pero trato de mantener mis artículos con cierta extensión y esto comenzó a extenderse un poco más de lo que quería. .
Entonces, la conclusión final de esta publicación, si tuviera que resumirla, es esta:
Los lenguajes tipeados dinámicamente, como PHP, no tienen el lujo de los lenguajes compilados donde todo se compila en un solo binario. Tenemos que decirle al programa, de alguna manera, dónde existen las dependencias dentro del contexto del programa más grande.
Y eso es lo que trataré de cubrir en la próxima publicación.