He notado algunas inconsistencias en el manual de PHP; Se documenta una serie de firmas de función central para aceptar argumentos por referencia, sin embargo, aceptan argumentos por valor.Argumentos PHP de funciones centrales; el manual dice referencia, sin embargo acepta valores
He publicado una más specific question anteriormente, y @cweiske proporciona una gran respuesta (con referencia a la fuente pertinente PHP), sin embargo estas inconsistencias parecen ser más desenfrenada.
Hay una serie de funciones que se ven afectados por esta (Voy a actualizar esta lista como órdenes; también la nota, estas pruebas se realizaron en un ambiente error_reporting(-1)
)
- http://www.php.net/manual/en/function.current.php
- Esto ya se discutió en la cuestión vinculada
- http://www.php.net/manual/en/function.key.php
- Esto ya se discutió en la cuestión vinculada
-
http://www.php.net/manual/en/function.array-replace-recursive.php-
array
array_replace_recursive
( array
&$array
, array
&$array1
[, array
&$
... ] )
- acepta argumentos
$array
,$array1
, etc., por valor. Esto ha sido corregido.
-
- http://www.php.net/manual/en/function.array-multisort.php
bool
array_multisort
( array
&$arr
[, mixed
$arg
=
SORT_ASC
[, mixed
$arg
=
SORT_REGULAR
[, mixed
$
... ]]] )
- acepta argumentos
$arr
, etc., por valor. Este debería arrojar un error, ya que no hará nada si el argumento no es una variable.
Ahora a mí respecta, no porque yo estoy siendo anal sobre la documentación, sino porque temo que los desarrolladores de PHP son en la valla de los detalles de implementación de estas funciones (o algo igualmente poco fiable)
Por ejemplo, uso array_replace_recursive()
, para tomar un argumento de matriz y aplicarlo contra otra matriz que contenga los valores predeterminados. Algunos de mi base de código se ha aprovechado de esta incoherencia, hacer simplemente:
$values = array_replace_recursive(array(
'setting_1' => array(
'sub-setting_1' => '',
'sub-setting_2' => '',
'sub-setting_3' => '',
),
'setting_2' => array(
'sub-setting_1' => 0,
'sub-setting_2' => 0,
),
'setting_3' => true,
), $values);
lo tanto la producción de una serie con formato correcto (de moverse gratuita isset()
llamadas)
¿Debo preocuparme con esto? Estoy pensando en enviar una solicitud de error relacionada con la documentación, pero primero tengo curiosidad si alguien en SO (mirando en su dirección @cweiske) tiene información sobre por qué esto se ha hecho.
Gracias @Brian - Mi dilema es que el punto no es discutible por el hecho de que los desarrolladores de PHP pueden haber documentado esto explícitamente porque hay un cambio en el horizonte. Si la función * no * modifica los argumentos, ¿por qué los define por referencia? Si la función * does * modifica los argumentos, ¿por qué aceptar los valores pasados? Si se trata de una supervisión de la documentación, y con 5.4, junto con todos los cambios/ramificaciones de la versión, (* como mencionó, 5.3, 6.0, etc. *), entonces es completamente comprensible. Sin embargo, la implementación permite pasar valores. Esto no parece correcto, y solo quiero saber por qué. – Dan
Ah, veo a dónde se dirige con que jaja su preocupación, entonces, es si pretenden modificar la forma en que funcionan estas funciones permitiéndoles tomar sus parámetros como referencias y trabajar directamente en ellos en lugar de exigir que el resultado de la función sea devuelto? Pude ver cómo eso podría ser un problema: P Lamentablemente, tampoco soy alguien que habitualmente indaga en la fuente de PHP, así que dejaré el campo de la pregunta a uno de los nerds más nerds aquí en la pila;) – Brian