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

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.

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 .

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?

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!

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.

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?

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.

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

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/

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.

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)

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

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

¡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 !

Las cadenas deben ser objetos

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.

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

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!

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.

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).

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.

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.

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 ()).

• 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.

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

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.

Sobrecarga del operador:

$result = $MatrixA + $MatrixB * $MatrixC;

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.

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!

Soporte de archivos grandes. ¿Bastante por favor?

Ver http://bugs.php.net/bug.php?id=27792 (aunque puede haber más áreas / funciones que también necesitan atención).

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.