Какие функции вы хотели бы иметь в PHP? [закрыто]

Так как сейчас сезон отпусков и все загадывают желания, мне интересно, какие языковые функции вы бы хотели добавить в PHP? Я заинтересован в некоторых практических предложениях / пожеланиях для языка. Под практическим я подразумеваю:

1. Что-то, что можно сделать практически (не: «Я бы хотел, чтобы PHP угадал, что означал мой код, и исправил бы ошибки для меня» или «Я хотел бы, чтобы любой код выполнялся менее чем за 5 мс»)
2. Что-то, что не требует изменения PHP на другой язык (не: «Я хотел бы, чтобы они сбрасывали знаки $ и использовали вместо скобок пробел» или «Я хотел бы, чтобы PHP был скомпилирован, статически типизирован и имел # в своем имени»)
3. Что-то, что не потребовало бы разрушения всего существующего кода (не: «Давайте переименуем 500 функций и изменим порядок параметров для них»)
4. То , что делает изменения языка или какой - нибудь интересный аспект этого (не: «Я хотел было расширение поддержки для протокола XYZ» или «Я хочу ошибка # 12345 окончательно фиксируется»)
5. Кое-что, что является чем-то большим, чем напыщенная речь (не: «Я бы хотел, чтобы PHP так плохо не сосал»)

У кого-нибудь есть добрые пожелания?

Редактирование мода: Станислав Малышев является основным разработчиком PHP.

Я не возражаю против именованных параметров.

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!');

К сожалению, разработчики PHP уже отказались от этой идеи .

Больше разыменования:

echo something_that_returns_array()[4];

Другие упоминали именованные параметры и более короткий синтаксис массива. Я также не возражаю против более короткого синтаксиса объектов.

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

$b1 = (object)array('name' => 'foo');
$b2 = {'name' => 'foo'}; // or something?

После работы с PHP в течение 13 лет и интенсивной работы с JS в течение 4 лет, я думаю, что PHP будет неплохо позаимствовать у JS:

1) сокращенная запись для массивов и объектов. Я полагаю, что это, возможно, обсуждалось и было сбито на Internals (так что я слышу - мне не нравится видеть, как производится колбаса), но я действительно, действительно нахожу, что буквенная запись для массивов и объектов в JS является большой производительность выиграть.

Например:

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

Разве (ИМХО) просто намного легче написать и чище, чем

$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';

Я слышал, что возникла некоторая обеспокоенность по поводу возможной путаницы, но на самом деле, это более запутанно, чем, скажем, запись heredoc? По крайней мере, я думаю, что создание объекта stdClass в PHP достаточно многословно, чтобы препятствовать этой практике.

2) Возможность переопределить ранее определенные функции и методы была бы действительно полезной. Это, в частности, упростит ситуации, когда расширение класса и создание нового класса будут чрезмерно сложными или непрактичными. Я думаю, что нам следует избегать переопределения основных и не пользовательских функций и методов.

В дополнение к этим двум, я думаю, PHP должен прозрачно поддерживать Unicode . Это становится все более и более серьезной проблемой для разработчиков, и решения, предлагаемые в настоящее время в PHP, сбивают с толку и часто не работают. Создание всей стандартной функциональности строк в удобном для Unicode виде, было бы огромной победой для программистов PHP.

Спасибо за вопрос!

Вещи, которые я хотел бы, как бывший давний апологет PHP:

1. Укороченный синтаксис для массивов. Массивы PHP - одна из самых удивительных особенностей языка из-за их гибкости, но писать их очень сложно some_array_method($argity, array('key' => $value));. Я считаю, что это предложение, к сожалению, уже исчезло в списке рассылки PHP.
2. finally служба поддержки
3. Атрибуты / аннотаций. Это позволяет вам добавлять пользовательское поведение в метод таким образом, чтобы можно было повторно использовать код. Например, в инфраструктуре MVC можно определить, AuthorizeAttributeкоторый будет указывать, что контроллер или метод действия требуют авторизации пользователя. Сам фреймворк будет отвечать за поиск атрибутов и соответственно на них действовать. Я полагаю, что PHPUnit уже использует своего рода атрибуты, помещая их в комментарии docblock, которые можно прочитать, используя отражение, но использование реальной функциональности в комментариях docblock, безусловно, является хаком.
4. Более короткий лямбда-синтаксис. Вместо того, чтобы писать function($x){ return $x*2;}, может быть, я мог бы написать $x => return $x*2, или что-то еще. Это опять-таки просто что-то вроде перетаскивания, чтобы использовать эту функцию. Например, $results = array_filter(array(1,2,3), function($a) { return $a % 2; }):против $results = array_filter(array(1,2,3), $a => return $a % 2 );первого просто гораздо больше сантехники, что в основном не имеет отношения к реальной работе, которую вы пытаетесь выполнить.
5. Встроенная Decimal(математика с фиксированной точкой), которая поддерживает математические операции через обычные операторы, была бы неплохой, так как у нас нет перегрузки операторов.
6. Магические магические методы. Магические методы великолепны. Я мог видеть, как PHP добавляет перегрузку операторов с помощью магических методов (я знаю, что в принципе этого никогда не произойдет). Но в целом, они предоставляют действительно отличные способы подключиться к языку и делать классные вещи.

Сделайте PHP действительно объектно-ориентированным. slap on another global functionЭволюция PHP должна закончиться.

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

Мне трудно это читать. Я должен сделать свой собственный умственный стек и отчасти собрать его сам. В основном это следует читать в обратном порядке. $dog->wakeup()->bark();легко читать по сравнению сbark(wakeup($dog))

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

Вы сделали шаг к включению поддержки объекта / метода, теперь, пожалуйста, используйте его в реальных функциях ядра PHP.

Давайте переименуем 500 функций и изменим порядок параметров для них.

Перенос этой функциональности на методы позволил бы их последовательно переименовывать. Не нарушит ли это обратную совместимость, если бы у строк и массивов были свои собственные методы?

Интегрированный в язык механизм запросов был бы хорош. Вроде как то, что доступно в .NET под названием LINQ. Это помогло бы сортировать массивные массивы данных и стандартизировать доступ к базам данных, чтобы было меньше успешных атак с использованием SQL-инъекций.

Ой. Тип подсказки для примитивов. Это было бы чудесно.

Я действительно желаю лучшей поддержки Unicode из коробки. Большинство языков движутся в этом направлении, но в PHP все еще есть странные команды.

Строки PHP - это просто байтовые массивы. Их содержимое непереносимо, так как оно зависит от текущей кодировки по умолчанию.

То же самое относится и к представлению, созданному сериализацией. Он содержит байтовое представление строки с префиксом длины без фактического хранения какой-либо информации кодирования.

Большинство PHP (строковых) функций не имеют никакого представления о Unicode. Подробный список с указанием уровня риска каждой функции см. По адресу : http://www.phpwact.org/php/i18n/utf-8.

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

Сделайте строковый объект похожим, со встроенными методами, чтобы заменить непоследовательно названные и параметризованные необъектные. например

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

и т.п.

Изменить: еще одна вещь: эти методы должны всегда ожидать и излучать UTF-8, за исключением тех, которые специально предназначены для работы с кодировками. Если ввод недействителен в формате UTF-8, должно быть сгенерировано исключение, даже если кодирование не повлияет на вывод функции.

1) Я бы хотел, чтобы вновь созданные объекты возвращали «$ this», чтобы я мог цепочку методов, $ user = new User ('john') -> setLastName ('Doe') -> save ();

2) Если вы когда-либо использовали ruby ​​и последний узел, у них есть отличная интерактивная оболочка (IRB). Я бы хотел, чтобы у PHP был такой, который был бы действительно полезен.

3) Черты / миксины, но я слышал, что они в пути.

4) Я хочу создать второй короткий массив $ myArray = ['my', 'array'];

5) Последовательное наименование / порядок (т.е. стог сена иглы)

1) Пожалуйста, избавьтесь от включает (). Ссылки на другие файлы должны быть ссылками, а не помещать содержимое одного файла исходного кода в другой. Слишком многие программисты PHP используют include () как тип вызова функции, а не как средство ссылки на библиотеку. Это приводит к разного рода неоднозначности в состоянии переменной и нестабильности кода. Замените это Perl-подобной командой use.

2) предоставьте готовый метод компиляции приложения PHP в один распространяемый файл байт-кода или исполняемый файл. Это значительно повысит привлекательность PHP как коммерческого языка разработки. Это должно быть основным компонентом языка. Не беспокойтесь о HTML-файлы, используемые для графического интерфейса приложения, потому что ...

3) избавьтесь от возможности вставлять теги PHP в HTML. Или, по крайней мере, обеспечить режим «без встраивания». Это абсолютный беспорядок и поощряет плохой дизайн, смешивая логику приложения и представление вместе. Разработчики должны использовать шаблоны для отображения, а не шлепать файлы PHP вместе и надеяться на лучшее.

Подпись,

GrandmasterB

PS: не слушайте то, что говорят здесь другие, я был хорош весь год

Директива ini для E_ERRORнеопределенных констант, а не для предположения, что это строка с E_NOTICE.

Нормализуйте глобальное пространство имен с помощью хорошо продуманного соглашения об именах, которое имеет смысл для новичков!

Процитируем нашего любимого Джеффа Этвуда: PHP - отстой, но это не важно !

Строки должны быть объектами

1) Сокращенный синтаксис массива / объекта, а-ля JavaScript (как упоминалось ранее)

2) Разрешить constпеременные, чтобы позволить результат вычисления, как это define()делает.

3) Цепочка напрямую от конструктора: new User()->name('Ryan');

4) Разыменование массива: something_that_returns_array()[4];

5) Расширенная поддержка SPL. SPL делает достойную работу по переосмыслению функций строк и массивов (среди прочего) как объектов. Расширение SPL могло бы решить множество проблем из-за того, что язык так дерзок.

6) Использование ArrayObject()должно быть таким же прозрачным, как и использование array(). Вы должны быть в состоянии делать вещи, как array_filter($array_object_instance)без дела array_filter($array_object_instance->getArrayCopy()). Даже лучше, конечно, было бы $array_object_instance->filter().

7) Полный Unicode был бы хорош.

8) Прекратите делать странные автоматические преобразования типов. Например, вы не сможете echoиспользовать объект SimpleXMLElement без предварительного явного ввода его в виде строки. Или, по крайней мере, бросить что-нибудь, когда это произойдет (например, в строгом режиме или в любом другом режиме error_reporting(-1)).

9) Поддержка нескольких потоков или каких-то четных / асинхронных обратных вызовов. Это наиболее важно при попытке загрузить большие файлы через cURL. Вместо веток старой школы, было бы неплохо что-то вроде Grand Central Dispatch от Apple. Или даже что-то вроде JavaScript, где вы можете делать асинхронные запросы и определять обратные вызовы.

10) Непротиворечивое именование / порядок (т.е. стог сена иглы) было бы неплохо, но я думаю, что это можно было бы лучше решить с помощью SPL.

11) Официально поддерживаемая интерактивная оболочка PHP, такая как IRB. У Facebook есть один, phpshкоторый был написан на Python, но ему не хватает того блеска, который я хотел бы увидеть.

12) Для API Reflection добавьте поддержку (а) комментариев докблока для констант (глобальных и классов) и (б) поддержки анализа комментариев, похожих на PHPDoc, в разумную структуру данных. Есть пакет PECL под названием «docblock», который пытается это сделать, но не похоже, чтобы автор зашел очень далеко.

РЕДАКТИРОВАТЬ: 13) Я также хотел бы видеть возможность использовать !и ?в именах функций - как Руби может.

1) Понимание массива в стиле понимания списка Python:

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

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

2) Синтаксис короткого массива

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

3) Сделайте empty () не считать строку '0' верной

Я хотел бы увидеть законный метод создания / определения массивов CONSTANT. Есть несколько хакерских способов симулировать такую ​​функциональность, но было бы неплохо, если бы это была простая функция PHP. Было бы неплохо, если бы вы могли создать массив способом, аналогичным «окончательному» объявлению Java.

Я создал систему входа в систему, которая очень быстро настраивается. Все, что вам нужно сделать, это изменить содержимое массива в текстовом файле, чтобы указать поля, которые вы хотите для пользовательской информации. Используя цикл for, он обрабатывает все: от генерации форм и сенсибилизации ввода до вызовов базы данных, но все это зависит от этого исходного массива.

Файл с массивом заблокирован с разрешениями, но как только массив перемещается в эфире, он изменчив. Хотя я чувствую, что система довольно безопасна, мне не нравится оставлять что-либо на волю случая. Метод для завершения массивов был бы хорош для такой ситуации.

Новая идея!!

Оооо, я подумал о чем-то еще, что мне бы очень понравилось в php. Я хотел бы, чтобы какая-то система управляла операциями с файлами php и операциями с каталогами, аналогично тому, как работает .htaccess.

Файл .phpaccess должен запускать какую-то политику в отношении того же домена / источника.

Например, если бы я размещал много сайтов с виртуальными хостами, у меня мог бы быть файл .phpaccess в каталоге, который велел бы php проверять происхождение любых выполняемых сценариев, которые пытаются работать с моим защищенным каталогом. Если скрипт не пришел из этого каталога или его подкаталогов, то файловые операции / или операции сокетов будут отклонены.

Я думаю, что такая система сделает виртуальный хостинг намного безопаснее. Если бы вы могли разместить один из них в верхней части каждого виртуального хоста, это уменьшило бы вероятность того, что кто-то найдет способ проникнуть с соседнего виртуального хоста.

Кроме того, если было бы хорошо иметь метод защиты в обратном порядке. то есть, ограничение доступа сценариев в одном каталоге к этому каталогу.

Это Инь и Ян Я знаю!

Два моих самых больших желания как программиста на PHP:

1. Поддержи наконец. Это большой беспорядок, чтобы вымышленно обойти это с помощью флагов или аналогичных средств.
2. Я хотел бы видеть поддержку синтаксиса C # для геттеров и сеттеров. Когда у вас много геттеров и сеттеров, простой синтаксис, такой как C #, значительно повышает производительность вместо того, чтобы делать это по-Java и писать методы геттеров и сеттеров. Магические методы хороши в тех случаях, когда вы хотите создавать элементы динамически (например, если вы хотите дать шаблону рендерера некоторые переменные для использования), но они не подходят для обычных свойств, для которых вы хотите, чтобы среда IDE автоматически заполнялась, знайте их типы и тд. это помогло бы сделать код меньше, а читаемым и простым в использовании.

Синтаксис языка : в pihipi и phpreboot есть несколько хороших подсказок о том, что интересует разработчиков (хотя phpreboot заходит слишком далеко, превращаясь в JS).

Методология разработки . Это значительно увеличило бы срок службы PHP.net, если бы такие обзоры были действительно приняты во внимание. Не принимайте больше решений по синтаксису послеобеденного IRC-сеанса.

Индивидуальные особенности : некоторые упоминались ранее, но я с удовольствием сожгу некоторую карму, чтобы быть здесь слишком тупой:

• Тип строки Unicode.
• Бигинт (см. Питон).
• Встроенный Runkit для удаления / переименования / переопределения встроенных функций и классов, которые не всегда хорошо спроектированы.
• Современный ООП
  • множественное наследование (вместо сложности для поддержки редко встречающихся случаев с синтаксисом неуклюжих признаков)
  • скаляры могут дублироваться как объекты (см. Python), например, array () работает как ArrayObject или строки как SplString (нужны пригодные для использования методы, все строковые функции должны быть доступны как str::toupper())
• Устаревайте дерьмовый \синтаксис пространства имен , исправьте синтаксический анализатор и примите в ::качестве альтернативы. Вы знаете, как настоящий язык.
• Любой вариант LINQ (хотя я не верю, что вы, ребята, изобрели разумный синтаксис)
• или литералы XML.
• Избавьтесь от поведения php.ini и семантических переключателей. Это снимает некоторые волнения, правда, но принесет пользу разработчикам и пользователям.
• Да, кавычки еще не ушли.
• Конвертировать байт-код Zend Engine в PBC

Хотя, если это не очевидно, я бы с радостью финансировал кого-то другого, чтобы сделать последнее, и убил php.net в качестве основной реализации. :P
О, только что заметил, это вики сообщества. Таким образом, есть шанс, что вы на самом деле здесь не ради кармы, а с неподдельным интересом. Если это так, посмотрите на <b> проблему </ b>, которая серьезно вредит языку (директориту).

Я хотел бы видеть объединение ошибок и исключений в единую концепцию (исключения). Замечательно иметь возможность отлавливать исключения и записывать их в журнал, таким образом находить и исправлять ошибки. Но если есть что-то принципиально неправильное (читай: ошибка PHP) в пути к коду, который встречается очень редко, нет хорошего способа направить эту информацию в ту же базу данных проблем.

Пожалуйста, Санта, добавь в php.ini переключатель, который превращает все ошибки в исключения - в идеале, исключения, которые я могу уловить в своем коде.

PHP мне подходит как раз для того, чтобы подгонять маленькие и средние сайты; Я, должно быть, немного не придумаю, единственное, что я могу придумать в качестве ответа на этот вопрос, это то, что делает его лучше масштабируемым для сайтов с высоким трафиком.

Я имею в виду создание процессов на других ядрах, например, обновление базы данных в одном процессе при создании страницы вывода в другом процессе. Быстрый поиск в Google показывает, что это можно смоделировать, но в настоящее время не поддерживается напрямую в php.

Я действительно пропустил, что скалярные типы не обрабатываются как объекты, и реальные объекты не могут действовать как любой другой тип или объект (за исключением строки из-за __toString ()).

• поддержка перечислений (например, Java 1.5+)
• Уметь определять типы возвращаемых методов в интерфейсах и классах
• поддержка аннотаций / определения метаданных о свойствах и методах.
• уметь делать строгие подсказки типов для скалярных аргументов метода.

Очистите "Пользовательские заметки" на http://php.net . Иногда они действительно беспорядок, хотя в целом представляют большую ценность.

В PHP есть несколько довольно приличных функций для работы с массивами, которые обеспечивают возможности обработки списков, обратные вызовы и create_function()базовое лямбда-исчисление.

Основная проблема в том, что он слишком многословен в PHP, система сокращений была бы превосходной, особенно в том, что касается команд map / lower.

Что еще более важно, функции списка не полностью завершены:

• нет foldrфункции, array_reduce()обеспечиваетfoldl
• array_map()должен передать ключ во втором аргументе, как array_walk()это делает
• array_map_keys()может быть полезным для ключевых изменений
• список понимание очень неуклюжее, range(), array_fill()и array_fill_keys()обрабатывать только так много дел, и array_filter()отдельно

Я не собираюсь превращать PHP в Haskell, но PHP часто используется для манипулирования структурой данных типа списка, и в этом отношении было бы полезно иметь полный набор инструментов.

Перегрузка оператора:

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

Добавлять исключения вместо создания E_WARNING ... Это очень раздражает, что я не могу использовать что-то вроде:

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();
}

Конечно, в настоящее время это не очень практично, но очень неприятно получать:

ПРЕДУПРЕЖДЕНИЕ

ПРЕДУПРЕЖДЕНИЕ

ПРЕДУПРЕЖДЕНИЕ

и я не могу контролировать поток кода, не написав свой собственный обработчик ошибок и обработчик строк, какая ошибка была вызвана (разрешение, неправильное имя файла или что-то еще; я не против других источников ошибок здесь), чтобы выдать правильное исключение ,

Надеюсь, мне не нужно объяснять, почему это важно.

Некоторое время назад PHP стал объектно-ориентированным, и мы, программисты, использующие PHP, с нетерпением ждем OO-функций, а не вводим «goto» ... Когда я узнал, что это действительно произошло, я подумал, что это был апрельский день дурака.

1. Объединить объектную модель - заставить все объекты расширять базовый класс объектов. Класс Object будет (среди прочего) реализовывать все магические методы (чтобы они больше не были магическими!)

2. Переместите расширения в свои собственные пространства имен - снимите загромождение с глобального пространства имен $conn = new \MySQLi\Connection();

3. Отключите spl_autoload()функцию! Серьезно, это, возможно, одна из величайших возможностей PHP, а также самая бесполезная в то же время. spl_autoloadэто автозагрузчик по умолчанию, который поддерживает пространства имен и несколько расширений файлов, но по неизвестной причине требует, чтобы имена файлов были в нижнем регистре. Для этого есть отчет об ошибке , но сотрудники ответили, что не исправят это из-за обратной совместимости. Правильно ... не каждый фреймворк поставляется с собственным автозагрузчиком, так как по умолчанию он поврежден!

Поддержка больших файлов. Довольно пожалуйста?

См. Http://bugs.php.net/bug.php?id=27792 (хотя может быть больше областей / функций, которые также требуют внимания).

Обеспечьте поддержку taint до последней версии и включите ее в стандартные сборки, предпочтительно включенные в конфигурации по умолчанию http://wiki.php.net/rfc/taint

Это предотвратит атаки XSS и SQL-инъекциями, заставляя людей правильно кодировать.