¿Por qué los arreglos de configuración son parámetros aceptables en PHP y Javascript?

Question

En la mayoría de los otros lenguajes orientados a objetos. Sería un sacrilegio que cada función reciba una sola matriz asociativa de objetos en lugar de enumerar cada uno en la firma del método. ¿Por qué, sin embargo, es aceptable y comúnmente utilizado en los marcos más populares para ambos idiomas para hacer esto?

¿Hay alguna justificación más allá de desear tener firmas de métodos concisas?

Veo un beneficio en esto: que la API podría permanecer sin cambios a medida que se agreguen nuevos parámetros opcionales. Pero Javascript y PHP ya permiten parámetros opcionales en sus firmas de métodos. En todo caso, parece que Java u otro lenguaje OO se beneficiarían más con esto ... y, sin embargo, rara vez veo este patrón allí.

¿Qué ofrece?

Answer 1

La razón principal es que esos idiomas particulares simplemente no admiten tener varias convenciones de llamadas para el mismo nombre de función. ES DECIR. no se puede hacer lo siguiente:

public function someFunc(SomeClass $some); 
public function someFunc(AnotherClass $another); 
public function someFunc(SomeClass $some, AnotherClass $another); 

por lo que debe encontrar otra manera de crear formas más simples para pasar sus variables de alrededor, en PHP terminamos con someFunc(array('some'=>$some, 'another'=>$another)) porque es la única manera conveniente. En JavaScript terminamos usando objetos, que no es tan malo: someFunc({some: something, another: anotherthing})

Answer 2

En mi opinión, muchas de estas funciones están subiendo en la cantidad de argumentos que aceptan, más de 10 no es poco común. Incluso si realiza parámetros opcionales, igual debe enviarlos en orden.

Considérese una función como:

function myFunc(a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13){ 
    //... 
} 

decir que quiere utilizar argumentos 3 y 11 solamente. Aquí está el código:

myFunc(null, null, null, 'hello', null, null, null, null, null, null, null, 'world'); 

¿No sería mejor simplemente:

myFunc({ 
    a3 : 'hello', 
    a11 : 'world' 
}); 

?

Answer 3

En primer lugar, tal técnica es muy simple para los codificadores.

No necesitan recordar el orden de todos los parámetros de todas las funciones en su aplicación. El código se vuelve más legible y más robusto.

Cualquier desarrollo futuro, mejoras o refactorización será tan difícil de proporcionar. El código se vuelve más sostenible.

Pero hay algunas trampas. Por ejemplo, no todos los IDE le darán un código simple que complete con tales funciones y sus parámetros.

Answer 4

Hay un par de razones para esto.

La primera es que no todas las listas de argumentos tienen un orden natural. Si hay un caso de uso para proporcionar únicamente el 1er y el 6to argumento, ahora debe completar cuatro marcadores de posición predeterminados. Jage lo ilustra bien.

La segunda es que es muy difícil recordar el orden en que deben aparecer los argumentos. Si toma una serie de números como argumentos, es poco probable saber qué número significa qué. Tome imagecopyresampled($dest, $src, 0, 10, 0, 20, 100, 50, 30, 80) como ejemplo. En este caso, la matriz de configuración actúa como los argumentos nombrados de Python.

Answer 5

En mi opinión hay 2 razones por las que esto ha evolucionado:

1. Array son muy fáciles de crear y manipular, incluso con tipos mixtos.
2. Los programadores PHP/JS a menudo tienen un trasfondo no académico y están menos adoctrinados de languanges como Java y C++.

Answer 6

Rubí sigue esta metodología también, e incluso ha ideado una sintaxis más sucinta específicamente destinado para el uso de hashes como inicializadores, como de Ruby 1.9:

# old syntax 
myFunc(:user => 'john', :password => 'password'); 

# new syntax 
myFunc(user: 'john', password: 'password'); 

El problema que se aborda es que, dentro de estos idiomas, no puede sobrecargar funciones basadas en el tipo de argumento. Esto da como resultado clases complejas con un único constructor que puede tener una lista de argumentos enorme y difícil de manejar. El uso de objetos tipo hash para suministrar parámetros permite una especie de pseudo-sobrecarga por nombre de parámetro en lugar de por tipo.

Mi único problema real con esta práctica es que se hace difícil de documentar sus argumentos: PHPDoc for variable-length arrays of arguments

Answer 7

Una de las razones más importantes por las que no se ve esto en otros lenguajes orientados a objetos es que es probable que esté refiriendo lenguajes compilados como C++ o Java.

El compilador es responsable de determinar, en tiempo de compilación no durante la ejecución, qué método desea llamar y esto normalmente se hace en función de la firma, por lo que básicamente debe hacerse de esta manera. Esta es también la forma en que se realiza la sobrecarga de métodos en estos idiomas.