¿Qué características te gustaría tener en PHP? [cerrado]

88

Dado que ahora es la temporada navideña y todo el mundo está pidiendo deseos, me pregunto: ¿qué características de lenguaje desearía que PHP hubiera agregado? Estoy interesado en algunas sugerencias prácticas / deseos para el idioma. Por práctico quiero decir:

  1. Algo que se puede hacer prácticamente (no: "Deseo que PHP adivine lo que significa mi código y solucione los errores por mí" o "Deseo que cualquier código se ejecute en menos de 5 ms")
  2. Algo que no requiere cambiar PHP a otro idioma (no: "Me gustaría que soltaran signos de $ y usaran espacio en lugar de llaves" o "Me gustaría que PHP se compilara, se escribiera de forma estática y tuviera # en su nombre")
  3. Algo que no requeriría romper todo el código existente (no: "Cambiemos el nombre de 500 funciones y cambiemos el orden de los parámetros para ellas")
  4. Algo que lo hace cambiar el idioma o algún aspecto interesante de ella (no: "Me gustaría que hubiera extensión de soporte para el protocolo XYZ" o "Deseo el bug # 12345 fueron finalmente fijo")
  5. Algo que es más que una queja (no: "Desearía que PHP no apestara tanto")

Alguien tiene buenos deseos?

Edición de modificaciones: Stanislav Malyshev es un desarrollador principal de PHP.

StasM
fuente
99
@Stan: Por mucho que desee evitar ese tipo de comentario, lo obtendrá de todos modos. Los problemas que las personas tienen con PHP están en gran medida en las categorías de cosas que está descartando en su publicación. [...]
Fishtoaster
24
[...] Estás diciendo "¿Cómo podemos mejorar la experiencia de ser golpeado en la cara sin realmente no golpearte en la cara?" Quiero decir, sí, obtener café gratis mientras nos golpean en la cara podría ser bueno, en realidad no aborda muchos de los problemas subyacentes con, bueno, ser golpeado en la cara. Entonces, aunque espero que obtenga algunas respuestas útiles aquí (como ya parece haber), no se sorprenda con las improductivas.
Fishtoaster
55
@Fishtoaster: si PHP se asocia con ser golpeado en la cara por usted, manténgase alejado de todo. Definitivamente no estás interesado en mejorarlo. Sucede que aunque hay personas que lo son. Este tema es para ellos, no para ti. Estoy seguro de que este sitio también tiene muchos temas para usted, este no es uno de ellos.
StasM
55
Estoy usando ser golpeado en la cara como ejemplo, una situación en la que las mejoras superficiales no son tan importantes; cuando los problemas de la mayoría de las personas son con lo subyacente. Ni siquiera estoy rechazando tu intento de obtener sugerencias para esas mejoras superficiales, solo estoy señalando por qué es probable que obtengas algunas respuestas inútiles, dada la situación.
Fishtoaster
66
@Fishtoaster: No todos, sorprendentemente , odian PHP, siempre me ha gustado. Muy flexible y rápido (para codificar).
Orbling

Respuestas:

119

No me importaría los parámetros con nombre.

getData(0, 10, filter => NULL, cache => true, removeDups => true);
// instead of:
getData(0, 10, NULL, true, true);

// or how about:
img(src => 'blah.jpg', alt => 'an albino platypus', title => 'Yowza!');

Desafortunadamente, los desarrolladores de PHP ya derribaron esa idea .

Nota para uno mismo - piense en un nombre
fuente
1
Es la lista de 2005. Muchas ideas se cerraron y luego renacieron. En realidad, si llega una buena implementación, hay una buena posibilidad de que sea aceptada.
StasM
21
Es mi característica favorita de Python. Hace que el código sea muy autodocumentado.
Keyo
77
@ Josh K: Está bien, pero la llamada 'matriz' es inútil si se quiere. Solo ofusca lo que REALMENTE estás tratando de hacer. Otra opción sería una sintaxis abreviada para matrices: make_img (['src' => 'blah.jpg', ...]);
Erik van Brakel
2
@Erik: Esa tampoco es una mala opción, digo por qué agregar este desorden a un idioma cuando ya puede hacerlo con un contenedor de matriz menor.
Josh K
44
@Erik: una sintaxis más relajada para las matrices (como el []operador de JavaScript ) sería una característica apreciada.
Josh K
93

Más desreferenciación:

echo something_that_returns_array()[4];

Otros han mencionado parámetros con nombre y una sintaxis de matriz más corta. Tampoco me importaría una sintaxis de objeto más corta.

$a1 = array(1, 2, 3, 4);
$a2 = [1, 2, 3, 4];

$b1 = (object)array('name' => 'foo');
$b2 = {'name' => 'foo'}; // or something?
Annika Backstrom
fuente
18
() [] la sintaxis ya está en el tronco. Desafortunadamente, los atajos de matriz fueron rechazados, pero espero la resurrección.
StasM
2
Me encantaría esta característica ¿Por qué podemos tener algo_que_revoluciones_objeto () -> 4, pero no con matrices?
Bala Clark
44
Javascript como la matriz y las notaciones de objetos se moverían. Como desarrollador front-end, eso es lo que más me molesta en el código php.
Bleep Bloop
1
@DisgruntledGoat Sí, ver:function something_that_returns_array() { return array( 'a', 'b', 'c', 'd', 'e' ); }
Annika Backstrom
2
@DisgruntledGoat: El problema con la ()->sintaxis es que solo funciona cuando se devuelve un objeto, para empeorar las cosas, incluso se requiere que el objeto tenga una propiedad / método del nombre especificado, que, de manera óptima, hace lo que espera que haga. , mientras acepta los parámetros que le ha dado y reza para que no requiera más ... etc, etc.
phant0m
72

Después de trabajar con PHP durante aproximadamente 13 años, y en gran medida con JS durante aproximadamente 4, hay un par de cosas que creo que PHP haría bien en tomar prestado de JS:

1) notación abreviada para matrices y objetos. Creo que esto puede haber sido discutido y derribado en Internals (así que escuché, no me gusta ver cómo se hace la salchicha), pero realmente, realmente encuentro que la notación literal para matrices y objetos en JS es muy grande La productividad gana.

Por ejemplo:

$arr     = [1,2,3,4];
$assoc   = [foo=>'bar', baz=>'boo'];
$stdobj  = {foo->'bar', baz->'boo'};

Es (en mi humilde opinión) mucho más fácil de escribir y más limpio que

$arr     = array(1,2,3,4); // not too bad
$assoc   = array("foo"=>'bar', baz=>'boo'); // not too bad either
$stdobj  = new stdClass; // this gets pretty rough
$stdobj->foo = 'bar';
$stdobj->baz = 'boo';

He oído que surgió cierta preocupación sobre la posible confusión, pero realmente, ¿es esto más confuso que, digamos, la notación heredoc? Al menos, creo que hacer un objeto stdClass en PHP es lo suficientemente detallado como para desalentar la práctica.

2) Ser capaz de redefinir funciones y métodos previamente definidos sería realmente útil. En particular, simplificaría las situaciones al extender una clase y crear instancias de la nueva clase es demasiado complejo o poco práctico. Sin embargo, creo que deberíamos evitar la redefinición de funciones y métodos básicos / no de espacio de usuario.


Además de esos dos, creo que PHP debe admitir de forma transparente unicode . Esto se está convirtiendo en un problema cada vez mayor para los desarrolladores, y las soluciones que se ofrecen actualmente en PHP son confusas y con frecuencia no funcionan. Hacer que todas las funciones de cadena estándar sean compatibles con Unicode de forma inmediata sería una gran victoria para los programadores de PHP.

¡Gracias por preguntar!

Funkatron
fuente
(2) mira el kit de ejecución. (3) unicode es difícil, especialmente porque la mayor parte del mundo exterior no es unicode. Tendríamos que matar el rendimiento o exigir que la gente haga mucho trabajo adicional (como hace Java). Es por eso que el esfuerzo php6 unicode no funcionó.
StasM
8
En cuanto a Unicode: puede ser difícil, pero sería enormemente útil (seguramente desarrollar PHP en sí mismo es difícil, pero proporciona grandes beneficios, ¿sí?) Quizás una solución sería habilitar Unicode transparente a través de una extensión con el compromiso de rendimiento entendido, como XHP? Gracias de nuevo.
Funkatron
55
$ object = (objeto) array ("foo" => 'bar', baz => 'boo');
mercutio
3
No veo cómo se puede ver "la mayor parte del mundo exterior no es unicode"? ¿Estás hablando de personas? ¿O algo mas? Porque la gran mayoría de las personas en el mundo (por un amplio margen) hablan idiomas que están mejor representados por Unicode.
Dean Harding
1
Definitivamente soporte unicode. El envío de cualquier tipo de aplicación utilizada a nivel mundial no se puede iniciar sin él. Si los desarrolladores de PHP piensan que la ingeniería en soporte unicode decente es fácil o no, no viene al caso. La gente lo necesita, y están abriéndose paso entre las fallas de la plataforma para hacerlo. Delphi lo hizo agregando otro tipo de cadena y convirtiéndolo en el predeterminado, con conversión implícita y un interruptor global para recuperar el comportamiento anterior. ¿Por qué PHP no puede hacerlo de la misma manera?
Joeri Sebrechts
48

Cosas que me gustaría, como un antiguo apologista de PHP:

  1. Sintaxis más corta para matrices. Las matrices PHP son una de las características más increíbles del lenguaje debido a su flexibilidad, pero es una tarea difícil de escribir some_array_method($argity, array('key' => $value));. Por desgracia, creo que esta propuesta ya fue eviscerada en la lista de correo de PHP.
  2. finally apoyo
  3. Atributos / anotaciones. Estos le permiten agregar un comportamiento personalizado a un método de manera que permita la reutilización del código. Por ejemplo, en un marco MVC, uno podría definir uno AuthorizeAttributeque indicaría que un controlador o método de acción requiere que el usuario esté autorizado. El marco en sí mismo sería responsable de buscar los atributos y actuar en consecuencia en consecuencia. Creo que PHPUnit ya usa una especie de atributo al colocarlos en los comentarios de docblock, que se pueden leer usando la reflexión, pero poner la funcionalidad real en los comentarios de docblock es ciertamente un truco.
  4. Sintaxis lambda más corta. En lugar de tener que escribir function($x){ return $x*2;}, tal vez podría escribir $x => return $x*2, o algo así. De nuevo, esto es algo que hace que sea un lastre usar esta función. Por ejemplo $results = array_filter(array(1,2,3), function($a) { return $a % 2; }):vs $results = array_filter(array(1,2,3), $a => return $a % 2 );El ex simplemente tiene mucho más plomería que es básicamente irrelevante para el trabajo real que está tratando de lograr.
  5. DecimalSería bueno tener una función integrada (matemática de punto fijo) que admitiera operaciones matemáticas a través de los operadores normales, ya que no tenemos sobrecarga de operadores.
  6. MÉTODOS MÁGICOS DE MOAR. Los métodos mágicos son geniales. Pude ver que PHP agregaba la sobrecarga de operadores a través de métodos mágicos (sé que esto básicamente nunca sucederá). Pero en general, proporcionan formas realmente excelentes de engancharse en el lenguaje y hacer cosas geniales.
davidtbernal
fuente
48

Haga PHP verdaderamente orientado a objetos. La slap on another global functionevolución de PHP necesita terminar.

array_merge(array_filter(array_intersect_key($arr1, $arr2), "is_int"), $arr3);

Esto me es difícil de leer. Tengo que hacer mi propio stack mental y compilarlo yo mismo. Básicamente debería leer al revés. $dog->wakeup()->bark();es fácil de leer en comparación conbark(wakeup($dog))

$arr1->array_intersect_key($arr2)->array_filter("is_int")->array_merge($arr3);

Ya ha dado el paso para habilitar el soporte de objetos / métodos. Úselo en las funciones centrales de PHP.

Cambiemos el nombre de 500 funciones y cambiemos el orden de los parámetros para ellas.

Cambiar esta funcionalidad a métodos les permitiría cambiarles el nombre usando algunos de manera consistente. ¿Rompería la compatibilidad con versiones anteriores si las cadenas y las matrices tuvieran sus propios métodos?

Keyo
fuente
3
Creo que la matriz no es un tipo de objeto es un gran error en PHP. Conduce a todo tipo de problemas. Desafortunadamente, es una cosa evolutiva. Sin embargo, puedes hacer lo que quieras aquí con extensión o espacio de usuario. Probablemente encajaría bien con SPL.
StasM
3
El mismo argumento se aplica a las cadenas. Solo me refiero a la falta de métodos en general. Lenguajes como Java, Python, C # etc.todos tienen un código mucho más legible. Supongo que está buscando características, pero arreglar lo que está roto en la OMI sería una mejor recompensa.
Keyo
66
No, no seas tonto. Seríadog_wake_up($dog); bark_dog($dog);
Matchu
2
En mi humilde opinión, cualquier nuevo método de cadena debe esperar y emitir UTF-8, y lanzar excepciones si la entrada no es válida UTF-8. Esto reduciría en gran medida la necesidad de una reelaboración importante del soporte Unicode.
rjmunro
1
@luiscubal No. Un parámetro adicional significará que no podemos agregar parámetros más adelante si inventamos cosas nuevas para agregar a la función. Por ejemplo, si $ string => trim () solo hizo espacios en blanco (como antes de 4.1.0), entonces su sistema diría $ string => trim ('ISO-8859-1') espacios en blanco recortados de las cadenas ISO-8859-1 . Si luego quisiéramos poder recortar cosas que no fueran espacios en blanco, no podríamos agregar el parámetro para eso, a menos que hagamos que las personas especifiquen primero la codificación. Deberíamos alentar a las personas a creer que cualquier texto en cualquier lugar que no sea UTF-8 está equivocado .
rjmunro
40

Un motor de consulta integrado en el lenguaje sería genial. Algo así como lo que está disponible en .NET llamado LINQ. Ayudaría a clasificar a través de matrices masivas de datos y estandarizar el acceso a la base de datos, para que tengan éxito menos ataques de inyección SQL.

Nick Berardi
fuente
2
¡Cualquier cosa que facilite las consultas parametrizadas obtiene mi voto!
Dean Harding
1
Creo que el acceso a base de datos normalizada es en realidad un beneficio muy importante de algo así como LINQ, porque creo que hace que la unidad de pruebas con burla de su base de datos los objetos más fácil (ya que estás burlando de código PHP en lugar de consultas SQL.)
davidtbernal
No creo que algo así deba entrar en el núcleo. encajaría mejor en una extensión
pecl
38

Oh. Sugerencias de tipo para primitivas. Eso estaría bien.

ruurd
fuente
1
Aunque me gusta el principio KISS de PHP (hasta cierto punto), lo recomiendo. La razón es que si quieres estar realmente a la defensiva, terminas con el mismo código de verificación de tipo en cada método de establecimiento. Podríamos dejarlo fácilmente si el idioma lo admitiera de forma nativa.
MicE
44
"Sugerencia de tipo" fue un nombre muy desafortunado, ya que no es "sugerencia", es una mecanografía estricta. Creo que la escritura estricta y primitiva estaría fuera de lugar en un lenguaje dinámico como PHP. La escritura coercitiva (lo mismo que hacen las funciones internas, pruebe strlen (123)) puede estar bien.
StasM
66
+1 por esto. Escribir sugerencias (o escribir estrictamente) en las declaraciones de funciones sería increíblemente útil y reduciría tanto si (! Is_int ()) basura en CADA Y CADA método.
Phil Sturgeon
55
@StasM No estoy de acuerdo. Está perfectamente dentro del alcance de un lenguaje dinámico para permitir al usuario elegir usar el idioma de una manera estáticamente tipada. Y permitiría una captura de errores mucho mejor. No tendría que usarlo si no quisiera, pero personalmente estoy harto de que se pasen las cadenas donde quería un int y luego tener que buscar a través del código para averiguar dónde se pasa la estúpida cadena. O bien, escriba verificar todo todo el tiempo.
Daniel Bingham
2
@StasM No hay absolutamente ninguna razón para que tenga que introducir variables totalmente tipadas estáticamente. Sí, cambiarías los errores en tu código. Ese sería todo el punto. El error ocurriría en el momento de la llamada a la función en lugar de dentro de la función, lo que le deja sin idea de dónde está ocurriendo el error. En cuanto a los errores de conversión de tipo, el error ocurriría, sí, en tiempo de ejecución, en la llamada a la función. Solucione el problema convirtiendo allí al tipo correcto. Mucho mejor que hacer que una cadena aparezca en una función esperando un int y sin saber de dónde.
Daniel Bingham
34

Realmente deseo un mejor soporte Unicode fuera de la caja. La mayoría de los lenguajes se mueven en esa dirección, pero PHP todavía tiene comandos extraños llenos por todas partes.

Las cadenas PHP son simplemente conjuntos de bytes. Su contenido no es portátil, ya que depende de la codificación predeterminada actual.

Lo mismo se aplica a la representación construida por serializar. Contiene una representación de byte con longitud prefijada de la cadena sin almacenar realmente ninguna información de codificación.

La mayoría de las funciones de PHP (cadena) no tienen idea de Unicode. Para obtener una lista detallada que incluye el nivel de riesgo de cada función, consulte: http://www.phpwact.org/php/i18n/utf-8

http://blog.ginkel.com/2010/03/php-unicode-support-or-the-lack-thereof/

Emil Stenström
fuente
El soporte Unicode resultó mucho más difícil de lo que se pensaba. Es por eso que el esfuerzo de php6 se detuvo. Por ahora, tenemos utf-8 y creo que la mejor manera de hacerlo sería agregar soporte utf-8 para funciones de cadena, tal vez como parte de la extensión intl.
StasM
3
Por cierto, la cita es incorrecta. Las cadenas PHP son matrices de bytes, pero su contenido es tan portátil como lo hace y no depende de la "codificación predeterminada": es solo una matriz de bytes, los quiere en utf8, pon utf8, quiere utf16, pon utf16. El enlace phpwact.org parece estar muerto.
StasM
1
Realmente espero que la extensión intl esté habilitada de forma predeterminada, por lo que las personas que necesitan UTF-8 (¿no todos?) No tuvieron que luchar contra sus hosts para que las funciones de cadena se comporten como se esperaba.
Emil Stenström
Además, gracias por la aclaración sobre las cadenas. He estado fuera de PHP por un tiempo, así que estoy un poco oxidado. En cambio, he peleado la guerra Unicode con Python, que tiene problemas similares a los de PHP, pero los resuelve en Python 3. Tener un "ö" sueco en tu nombre es un desastre :)
Emil Stenström
Esta es definitivamente un área en la que me gustaría ver una mejora.
Nathan Osman
32

Haga que las cadenas sean objeto, con métodos incorporados para reemplazar los que no son objeto y son parametrizados de manera inconsistente. p.ej

$subject->replace($search,$replace);
$string->split($separator);
$string->trim();

etc.

Editar: una cosa más: estos métodos siempre deben esperar y emitir UTF-8, excepto aquellos específicamente diseñados para tratar codificaciones. Si la entrada no es válida UTF-8, se debe lanzar una excepción, incluso si la salida de la función no se vería afectada por la codificación.

revs rjmunro
fuente
arriba, eso es exactamente a lo que apunto.
Kemo
1
subject->verb(object), hace que el orden de los parámetros sea más fácil de recordar.
Ming-Tang
+1 Jugué creando mi propia clase de cadena para hacer este tipo de cosas, hace que la codificación sea mucho más fácil y nunca olvides el orden de los parámetros.
DisgruntledGoat
2
Entonces, ¿qué is_object($string)volvería? Esto rompería la compatibilidad hacia atrás a lo grande, o daría como resultado la introducción de objetos realmente poco intuitivos, pero no del todo.
Tgr
@Tgr: is_object () debe estar en desuso: no debe haber "no un objeto". A corto plazo, tendría que ser una propiedad que puede desactivar en cualquier objeto, y los constructores de cadenas predeterminados lo desactivarían.
rjmunro
24

1) Me encantaría que los objetos recién instanciados devuelvan "$ this" para poder encadenar el método $ user = new User ('john') -> setLastName ('Doe') -> save ();

2) Si alguna vez ha usado ruby, y el nodo más reciente, tienen un gran shell interactivo (IRB). Me encantaría que PHP tuviera uno que fuera realmente útil.

3) Rasgos / Mixins, pero escuché que están en camino.

4) Quiero secundar la matriz corta $ myArray = ['my', 'array'];

5) Nombramiento / orden consistente (es decir, pajar de agujas)

Jakefolio
fuente
¡Odio tener que crear un create()método que no haga nada especial solo para trabajar alrededor del # 1!
Alan Pearce
Hago lo mismo pero, usando el enlace estático tardío y una superclase de objeto, de esa manera cada clase que extiende mi superclase tiene el método, por ejemplo: SomceClass extiende SuperObject {}; SomeClass :: create () -> somemethod ();
dukeofgaming
Echa un vistazo a github.com/philsturgeon/php-ps Es solo un comienzo, pero con algo de ayuda podría ser bastante útil.
Phil Sturgeon
1
También hay un paquete PEAR que ofrece un shell interactivo para codificar experimentos rápidos en PHP, disponible en pear.php.net/package/PHP_Shell
kguest
(new Foo ()) -> bar () es parte de 5.4. 3) y 4) también lo son.
StasM
20

1) por favor deshacerse de incluye (). Las referencias a otros archivos deben ser referencias y no colocar el contenido de un archivo de código fuente en otro. Demasiados programadores PHP usan include () como un tipo de llamada de función en lugar de un medio para hacer referencia a una biblioteca. Esto conduce a todo tipo de ambigüedad en estado variable y código inestable. Reemplace esto con un comando 'use' similar a Perl.

2) proporcione un fuera de la caja método para compilar una aplicación PHP en un solo archivo de código de bytes distribuibles o ejecutable. Esto mejorará en gran medida el atractivo de PHP como lenguaje de desarrollo comercial. Este debería ser un componente básico del lenguaje. No se preocupe por los archivos html utilizados para la GUI de una aplicación porque ...

3) elimine la capacidad de incrustar etiquetas PHP en HTML. O al menos proporcione un modo 'sin incrustar'. Esto es un desastre absoluto y fomenta el mal diseño al mezclar la lógica de la aplicación y la presentación. Los desarrolladores deberían usar plantillas para mostrar y no juntar archivos PHP y esperar lo mejor.

Firmado

Gran maestro B

PD: no escuches lo que otros dicen aquí, he sido agradable todo el año

Gran maestro B
fuente
37
1) Incluye son geniales. Todo tiene incluye. 2) Esto es bueno. 3) La plantilla es la característica más fuerte de PHP . Obligarlo a usar alguna otra mierda de plantillas sería un movimiento muy malo.
Josh K
8
Me gustan (1) y (2), pero (3) parece un paso retrógrado. PHP te da el poder de creación de plantillas, depende de ti si lo usas sabiamente o no.
geekbrit
11
3 no tiene sentido: incrustar etiquetas es necesario para cualquier V en marcos MVC.
Alex
99
Leí esta respuesta como "Querido Santa, haz que PHP no sea PHP".
Stephen
1
3 está listo, ya que PHP es un lenguaje de plantillas.
Andrew
18

Una directiva ini para E_ERRORconstantes indefinidas, en lugar de asumir que es una cadena con E_NOTICE.

Annika Backstrom
fuente
1
Las constantes de clase hacen eso, por cierto.
StasM
44
En serio, no entiendo por qué hacen que PHP asuma cadenas sin comillas. Es la cosa más estúpida de todas. Yo elegiría cualquiera E_ERRORo E_PARSE.
BoltClock
14

¡Normalice el espacio de nombres global con una convención de nomenclatura bien pensada que tenga sentido para los recién llegados!

Para citar a nuestro amado Jeff Atwood: ¡ PHP apesta pero no importa !

David Murdoch
fuente
1
Estoy de acuerdo en principio, pero no tengo idea de cómo hacerlo en la práctica :)
StasM
3
@StasM: Me imagino que el primer paso sería crear las nuevas versiones de las bibliotecas con espacios de nombres y permitir que los programadores (a través de la configuración ini) desactiven las bibliotecas globales actuales. Creo que un paquete de compatibilidad estaría en orden para versiones anteriores, pero no debería ser muy difícil de escribir.
Michał T
13

1) Sintaxis de matriz / objeto más corta, a la JavaScript (como se mencionó anteriormente)

2) Permitir constvariables para permitir el resultado de un cálculo como lo define()hace.

3) Encadenamiento directamente desde el constructor: new User()->name('Ryan');

4) Desreferenciación de matriz: something_that_returns_array()[4];

5) Soporte SPL ampliado. SPL hace un trabajo decente al reinventar las funciones de cadena y matriz (entre otras cosas) como objetos. Expandir SPL podría resolver muchas quejas sobre que el lenguaje es tan extraño.

6) El uso ArrayObject()debe ser tan transparente como el uso array(). Deberías poder hacer cosas array_filter($array_object_instance)sin hacer array_filter($array_object_instance->getArrayCopy()). Incluso mejor, por supuesto, lo sería $array_object_instance->filter().

7) Unicode completo sería bueno.

8) Deja de hacer extrañas conversiones automáticas de tipos. Por ejemplo, no debería poder crear echoun objeto SimpleXMLElement sin primero escribirlo explícitamente como una cadena. O al menos, arroje algo cuando suceda (por ejemplo, en modo estricto o en cualquier modo error_reporting(-1)).

9) Soporte para múltiples hilos, o algún tipo de devoluciones de llamadas igualadas / asincrónicas. Esto es más importante cuando se intenta cargar archivos grandes a través de cURL. En lugar de hilos viejos, algo como el Grand Central Dispatch de Apple sería bueno. O incluso algo parecido a JavaScript donde puede realizar solicitudes asíncronas y definir devoluciones de llamada.

10) La asignación de nombres / orden consistentes (es decir, pajar de agujas) sería bueno, pero creo que esto podría resolverse mejor con SPL.

11) Un shell PHP interactivo oficialmente compatible, como IRB. Facebook tiene una llamada phpshque fue escrita en Python, pero carece del esmalte que me gustaría ver.

12) Para la API Reflection, agregue soporte para (a) comentarios de docblock en constantes (global y clase), y (b) soporte para analizar comentarios similares a PHPDoc en una estructura de datos sensible. Hay un paquete PECL llamado "docblock" que intenta hacer esto, pero no parece que el autor haya llegado muy lejos.

EDITAR: 13) También me encantaría ver la capacidad de usar !y ?en los nombres de las funciones, como Ruby can.

Ryan Parman
fuente
Estoy de acuerdo, que arrayobject debe ser compatible con las funciones array_ *. pero cuál sería el resultado esperado para algo como "array_merge" si considera las subclases de arrayobject. ¿solo se le permitiría fusionar instancias de la misma clase y qué devolvería array_merge? ¿Una matriz php o una instancia de arrayyoject (respectivamente, es una subclase)?
harald
Yo diría que, dado que los datos internos son una matriz, y ArrayObject lo envuelve con funcionalidad, incluso las subclases de ArrayObject seguirían trabajando con matrices internamente. Esperaría poder fusionar otra matriz estándar o ArrayObject (o subclase). En cuanto a lo que devolvería, argumentaría que también debería devolver un nuevo ArrayObject, pero siga el precedente que simplexml_load_string () establece donde puede especificar el nombre de la clase de la que el resultado debería ser una instancia.
Ryan Parman
12

1) Comprensión de matriz al estilo de la comprensión de la lista de Python:

$newlist = array($x->something for $x in $oldlist);

//with short array syntax:
$newlist = [$x->something for $x in $oldlist];

2) sintaxis de matriz corta

$newlist = [1,2,3,4,...];

3) Hacer vacío () no considerar la cadena '0' como verdadera

sfrench
fuente
2
Creo que para (1) algo cocinado desde iterador y cierre sería mejor.
StasM
+1 en mi humilde opinión, esto debe incluirse en todos los idiomas, así como en los iteradores. Son útiles para no tener.
Evan Plaice
empty()es el opuesto lógico de if ($x), por lo que tiene sentido que empty('0')sea ​​cierto, porque if ('0')es falso. La única diferencia es empty()que no arroja un aviso si la variable no está establecida.
Andrew
12

Me gustaría ver un método legítimo para crear / definir matrices CONSTANTES. Hay algunas formas difíciles de simular este tipo de funcionalidad, pero sería bueno si fuera solo una función directa de PHP. Sería bueno si pudiera crear una matriz de una manera similar a la declaración "final" de Java.

Creé un sistema de inicio de sesión que es muy rápido de configurar. Todo lo que tiene que hacer es cambiar el contenido de una matriz en un archivo de texto para especificar los campos que desea para la información del usuario. Usando una serie de bucles for, maneja todo, desde la generación de formularios y la sensibilización de entrada, hasta las llamadas a la base de datos, pero todo depende de esta matriz original.

El archivo con la matriz está bloqueado con permisos, pero una vez que la matriz se mueve en el éter es mutable. Aunque siento que el sistema es bastante seguro, no me gusta dejar nada al azar. Un método para finalizar matrices sería bueno para una situación como esta.

¡¡Idea Nueva!!

Ohhh, pensé en algo más que realmente me gustaría en php. Me gustaría algún tipo de sistema para controlar las operaciones de archivos php y las operaciones de directorio similares a la forma en que funciona .htaccess.

El archivo .phpaccess debería desencadenar algún tipo de política de mismo dominio / mismo origen.

Por ejemplo, si estuviera alojando muchos sitios con hosts virtuales, podría tener un archivo .phpaccess en un directorio que le indicaría a php que verifique el origen de cualquier script que se esté ejecutando y que esté tratando de operar en mi directorio protegido. Si el script no vino de ese directorio o sus subdirectorios, las operaciones de archivos / operaciones de socket serán denegadas.

Creo que un sistema como este haría que el alojamiento virtual sea un entorno mucho más seguro. Si pudiera colocar uno de estos en la parte superior de cada host virtual, disminuiría la posibilidad de que alguien encuentre una manera de colarse desde un host virtual vecino.

También si sería bueno tener un método para asegurarlo al revés de esta manera. es decir, restringir el alcance de los scripts en un solo directorio a ese directorio.

Es el yin y el yang ya sabes!

Dave B.
fuente
+1 para final. Para aclarar: finalsignifica que el valor de una variable se puede establecer en tiempo de ejecución (a diferencia de las constantes, que deben ser expresiones constantes), pero solo se puede establecer una vez. Ver también C # 's readonly.
davidtbernal
1
hay una propuesta para getters / setters para troncal que reemplazaría a solo lectura, etc. Las matrices inmutables, aunque probablemente serían difíciles de hacer.
StasM
Re phpaccess, PHP ya tiene un "modo seguro" que hace lo que usted describe.
DisgruntledGoat
11

Mis dos mayores deseos como programador PHP incondicional:

  1. Apoyo finalmente. Es un gran lío evitar esto ficticiamente a través de banderas o medios similares.
  2. Me ENCANTARÍA ver soporte en la sintaxis de C # para getters y setters. Cuando tiene muchos getters y setters, una sintaxis simple como C # es un gran refuerzo de rendimiento en lugar de hacerlo de la manera Java y escribir métodos getter y setter. Los métodos mágicos son geniales en los casos en que desea crear miembros dinámicamente (por ejemplo, si desea darle a un renderizador de plantillas algunas variables para usar), pero no son buenos para las propiedades normales en las que desea que el IDE se complete automáticamente, conozca sus tipos, y así sucesivamente. Esto ayudaría a hacer el código más pequeño y aún más legible y fácil de usar.
Johnco
fuente
1
1. desafortunadamente, es difícil de hacer, pero definitivamente es un buen ítem para hacer 2. wiki.php.net/rfc/propertygetsetsyntax
StasM
@StasM: ¿qué tal hacerlo a través de anotaciones? Algo en la línea de: / ** @get getFoo; @set setFoo; * / privado $ foo;
Michał T
9

Sintaxis del lenguaje : hay algunas buenas pistas en pihipi y phpreboot de lo que les interesa a los desarrolladores (aunque phpreboot va demasiado lejos y se convierte en JS).

Metodología de desarrollo : mejoraría enormemente la vida útil de PHP.net si tales encuestas se tuvieran realmente en cuenta. No tome más decisiones de sintaxis de sesión de IRC tarde o noche.

Características individuales : Algunas se han mencionado antes, pero felizmente quemaré algo de karma para ser más contundente aquí:

  • Tipo de cadena Unicode.
  • Bigint (ver Python).
  • Runkit incorporado para eliminar / renombrar / anular funciones y clases incorporadas, que no siempre están tan bien diseñadas.
  • OOP moderna
    • herencia múltiple (en lugar de complejidad para admitir casos poco frecuentes con sintaxis de rasgos torpes)
    • los escalares pueden duplicarse como objetos (ver Python), por ejemplo, array () funciona como ArrayObject, o cadenas como SplString (necesita métodos utilizables, todos los funcs de cadenas deberían estar disponibles como str::toupper())
  • Desprecia la \sintaxis del espacio de nombres de mierda , arregla el analizador y adopta ::como alternativa. Ya sabes, como un lenguaje real.
  • Cualquier variación de LINQ (aunque no confío en ustedes, ideen una sintaxis sensata)
  • o literales XML.
  • Deshágase del comportamiento en tiempo de ejecución php.ini y los conmutadores semánticos. Saca algo de la emoción, es cierto, pero beneficiaría a los desarrolladores y a la base de usuarios.
  • Sí, las comillas mágicas aún no se han ido.
  • Convierta el bytecode de Zend Engine a PBC

Aunque, si esto no es obvio, me encantaría financiar a alguien más para hacer lo último, y eliminaría php.net como implementación principal. :P
Oh, acabo de notar, es wiki de la comunidad. Por lo tanto, existe la posibilidad de que en realidad no estés aquí por el karma, sino de un interés genuino. Si es así, examine el <b> problema </b> que daña gravemente el lenguaje (directoritis).

mario
fuente
55
Odio la sintaxis del espacio de nombres, pero es una historia larga y triste por qué se hizo así y probablemente no va a cambiar ... Probablemente, si pudiera cambiar solo una cosa en PHP, sería mi candidato principal. Pero es lo que es.
StasM
@StasM: Gracias por los comentarios y perdón por ser grosero con algunas cosas de PHP, pero me importa PHP; por lo tanto muy obstinado. - He leído un poco sobre el razonamiento. El dilema de la barra diagonal inversa aún no es un problema muy grande, pero se convertirá el próximo año cuando las bibliotecas se extiendan. Así que espero que alguien escriba un analizador que reescriba \ cargo \ culto \ clase \ nombres de nuevo a los esquemas de subrayado.
Mario
Tal vez soy tonto, pero ¿cuál es la diferencia si usamos '::' o '\' para espacios de nombres?
Michał T
@Pies: ::habría sido más natural para cualquier lenguaje de cierre de sintaxis C / C ++. Y `\` no solo es anormal entre todos los lenguajes de programación, sino que tiene connotaciones no probadas. Algunas discusiones anteriores: stackoverflow.com/questions/238550/… o developers.slashdot.org/article.pl?sid=08/10/26/1610259 y reddit.com/r/programming/comments/79cut/… - Pero en En particular, decidir eso sin comentarios y señalar a la comunidad de desarrolladores que lo asimilen no fue un movimiento muy bienvenido.
mario
1
+ 1000000 para herencia múltiple.
ts01
8

Me encantaría ver la unificación de Errores y Excepciones en un solo concepto (Excepciones). Es genial poder detectar excepciones y escribirlas en un registro, para encontrar y corregir errores de esa manera. Pero si hay algo fundamentalmente incorrecto (léase: Error de PHP) en una ruta de código que rara vez se alcanza, no hay una buena manera de canalizar esa información en la misma base de datos de problemas.

Por favor, Santa, introduce un interruptor en php.ini que convertiría todos los errores en excepciones, idealmente, excepciones que puedo detectar en mi código.

Alex
fuente
1
Ya hay soporte en el motor para eso y muchas extensiones lo usan. También puede hacerlo fácilmente con set_error_handler () y ErrorException. Tenga cuidado con E_STRICT / E_NOTICE / E_DEPRECATED aunque ...
StasM
Soy muy consciente de estos métodos y son realmente hacky. Me encantaría una forma unificada, la que incluye E_STRICT / E_NOTICE y tal.
Alex
7

PHP me queda bien, ya que es para crear sitios web pequeños y medianos; Debo ser poco imaginativo, lo único que podría pensar como respuesta a esta pregunta sería algo que lo haga escalar mejor para sitios de alto tráfico.

Estoy pensando en términos de generar procesos a otros núcleos, por ejemplo, actualizar una base de datos en un proceso mientras se crea la página de salida en otro proceso. Una búsqueda rápida en Google indica que esto se puede simular, pero actualmente no se admite directamente en PHP.

geekbrit
fuente
1
En realidad, pensando más en ello, la descarga de la base de datos parece ser un escenario interesante, así que +1 en eso :)
StasM
1
@Stasm, supongo que quiere decir que las solicitudes separadas se ejecutan como procesos separados. Estoy hablando de una página compleja que requiere generación de páginas y cómputo en segundo plano. Podría estar equivocado, pero no creo que haya una manera de generar (por ejemplo) las operaciones de actualización de la base de datos en un proceso separado. La razón para hacerlo sería enviar la página al solicitante antes, en lugar de tener que esperar a que todo el procesamiento que no está directamente relacionado con la producción de la página se complete en serie. PD .. ¡Gracias por la actualización!
geekbrit
7

Realmente extrañé que los tipos escalares no se traten como objetos, y los objetos reales no pueden actuar como cualquier otro tipo u objeto (a excepción de la cadena debido a __toString ()).

pestaa
fuente
Sí, métodos mágicos para encasillar, por favor.
Michał T
7
  • soporte para enumeraciones (como java 1.5+)
  • Poder definir tipos de retorno de métodos, en interfaces y clases
  • Soporte para anotaciones / definición de metadatos en propiedades y métodos.
  • ser capaz de hacer sugerencias de tipo estrictas para argumentos escalares de métodos.
Kees van Dieren
fuente
+1 Como me gustaría ver todas esas cosas en PHP.
Jeremy
6

Limpie las "Notas contribuidas por el usuario" en http://php.net . A veces son un verdadero desastre, aunque en general son de gran valor.

bobah
fuente
1
Algún tipo de funcionalidad de voto arriba / abajo y la capacidad de vincular al comentario original en la respuesta sin duda sería bueno.
Tgr
5

Hay algunas funciones de matriz bastante decentes en PHP, que proporcionan capacidad de procesamiento de listas, con devoluciones de llamada y create_function()proporcionan un cálculo lambda básico.

El principal problema con esto es que es demasiado detallado en PHP, un sistema abreviado sería excelente, particularmente en lo que respecta a los comandos map / reduce.

Más importante aún, las funciones de la lista no están completamente completas:

  • no hay foldrfunción, array_reduce()proporcionafoldl
  • array_map()debe pasar la clave en el segundo argumento, como lo array_walk()hace
  • un array_map_keys()podría ser útil para la modificación de clave
  • Lista de comprensión es muy torpe, range(), array_fill()y array_fill_keys()sólo manejan tantos casos, y array_filter()es independiente

No pretendo hacer PHP en Haskell, pero PHP a menudo se usa para la manipulación de la estructura de datos de tipo de lista y sería útil tener un conjunto completo de herramientas a este respecto.

Orbling
fuente
1
Un colega mío también cree que podría / debería haber otras adiciones para volver a configurar funciones relacionadas; como se menciona en su cuenta de github: Estas son la falta de array_all () y array_any (), que verifican si * una condición representada por una devolución de llamada se cumple para todos o alguno de los elementos de una matriz. gist.github.com/44350
kguest
5

Sobrecarga del operador:

$result = $MatrixA + $MatrixB * $MatrixC;
Ratones
fuente
1
No estoy seguro de qué tan bien haría clic con PHP como un lenguaje de tipo dinámico.
BoltClock
55
Tal vez debería hacerse a través de métodos mágicos, como __add ($ obj), __times ($ obj) etc.
Michał T
ya existe como una extensión PECL: pecl.php.net/package/operator . No debería ser demasiado trabajo fusionarlo con la fuente principal
Xananax
4

Agregue excepciones en lugar de producir E_WARNING ... Es muy molesto que no pueda usar algo como:

try{
   $f = fopen('asd', 'r');
   flock($f, LOCK_SH);

   while(!feof($f)){
       echo fread($f, 512);
   }

   fclose($f);

}catch(IOException $ex){
   echo 'Oops, something wrong: '.$ex->getCode();
}

Por supuesto, actualmente no es muy práctico, pero es muy molesto recibir:

ADVERTENCIA

ADVERTENCIA

ADVERTENCIA

y no puedo controlar el flujo de código sin escribir mi propio error_handler y detectar el error que se ha producido (permiso, nombre de archivo incorrecto o cualquier otra cosa; no me importan otras fuentes de errores aquí) para lanzar la excepción correcta .

Espero no tener que explicar por qué es importante.

PHP se volvió orientado a objetos hace mucho tiempo y nosotros, los programadores que usamos PHP, estamos esperando las funciones OO, no introduciendo "goto" ... Cuando descubrí que realmente sucedió, pensé que era un día de los Inocentes.

eRIZ
fuente
A menos que sea atrapado, la excepción matará el guión. La advertencia, en un servidor de producción, se registrará y nunca se mostrará al usuario. Cambiar esta funcionalidad ahora rompería muchos scripts porque no están diseñados para atraparlo. (Tenga en cuenta que escribo controladores de errores para lanzar excepciones yo mismo). Ahora, las cosas PDO pueden lanzar advertencias o excepciones: el programador decide en tiempo de ejecución. Esa funcionalidad es probablemente una que debería agregarse a más módulos.
Reece45
4
  1. Consolide el modelo de objetos: haga que todos los objetos extiendan la clase de objeto base. La clase Object (entre otras cosas) implementaría todos los métodos mágicos (¡para que ya no sean mágicos!)

  2. Mover extensiones a sus propios espacios de nombres: despeje el espacio de nombres global $conn = new \MySQLi\Connection();

  3. ¡Deshabilita la spl_autoload()función! En serio, esta es posiblemente una de las mejores características de PHP y también la más inútil al mismo tiempo. spl_autoloades el cargador automático predeterminado, que admite espacios de nombres y múltiples extensiones de archivos, pero por alguna razón desconocida requiere que los nombres de los archivos estén en minúsculas. Hay un informe de error lleno para esto , pero el personal respondió que no lo solucionarán debido a la compatibilidad con versiones anteriores. Correcto ... ¡no es que cada framework se envíe con su propio cargador automático, ya que el predeterminado está dañado!

revs Mchl
fuente
4

Lleve el soporte Taint a la última versión e inclúyalo en compilaciones estándar, preferiblemente activado en la configuración predeterminada http://wiki.php.net/rfc/taint

Esto evitaría los ataques de inyección XSS y SQL al hacer que las personas codifiquen correctamente.

revs rjmunro
fuente