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

88

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

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

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

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

StasM
источник
9
@Stan: Как бы вы ни хотели избежать такого комментария, вы все равно получите его. Эти проблемы люди имеют с PHP в основном в категориях вещей , которые вы исключающие в вашем посте. [...]
Fishtoaster
24
[...] Вы говорите: «Как мы можем улучшить восприятие удара по лицу, фактически не ударив вас по лицу?» Я имею в виду, да, получить бесплатный кофе, пока нас бьют по лицу, было бы неплохо, на самом деле это не решает многих основных проблем, связанных с ударом по лицу. Поэтому, хотя я надеюсь, что вы получите здесь несколько полезных ответов (как они уже есть), не удивляйтесь непродуктивным.
Fishtoaster
5
@ Fishtoaster: если PHP ассоциируется с ударом по лицу, во что бы то ни стало, держитесь от него подальше. Вы определенно не заинтересованы в улучшении этого. Так бывает, хотя есть люди, которые есть. Эта тема для них, а не для вас. Я уверен, что на этом сайте тоже есть много тем, но это не одна из них.
StasM
5
В качестве примера я использую удар по лицу - ситуация, когда поверхностные улучшения не так важны; когда проблемы большинства людей с основной вещью. Я даже не сбиваю с толку вашу попытку получить предложения об этих поверхностных улучшениях - я просто указываю, почему вы, вероятно, получите несколько бесполезных ответов, учитывая ситуацию.
Fishtoaster
6
@ Fishtoaster: Не все, что удивительно , ненавидят PHP - мне всегда это нравилось. Очень гибкий и быстрый (для кодирования).
Orbling

Ответы:

119

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

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 уже отказались от этой идеи .

Примечание для себя - придумай имя
источник
1
Это список с 2005 года. Многие идеи были закрыты, а затем возрождены. На самом деле, если будет хорошая реализация, есть хороший шанс, что она будет принята.
StasM
21
Это моя любимая особенность Python. Делает код очень самодокументированным.
Кейо
7
@ Джош К: Это возможно, но вызов 'array' - бесполезный мусор, если хотите. Это только запутывает то, что вы ДЕЙСТВИТЕЛЬНО пытаетесь сделать. Другой вариант - сокращенный синтаксис для массивов: make_img (['src' => 'blah.jpg', ...]);
Эрик ван Бракел
2
@Erik: Это тоже неплохой вариант, я говорю, зачем добавлять этот беспорядок в язык, если вы можете сделать это уже с помощью вспомогательной оболочки.
Джош К
4
@Erik: более понятный синтаксис для массивов (например, []оператор JavaScript ) был бы полезен .
Джош К
93

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

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?
Анника Бэкстрем
источник
18
() [] Синтаксис уже находится в транке. К сожалению, ярлыки массивов были отклонены, но я надеюсь на воскресение.
StasM
2
Я хотел бы эту функцию. Почему у нас может быть нечто_that_returns_object () -> 4, но не с массивами?
Бала Кларк
4
Javascript, как массив и объектные нотации будет качаться. Как разработчик внешнего интерфейса, это то, что беспокоит меня больше всего в PHP-коде.
Bleep Bloop
1
@DisgruntledGoat Это делает, см .:function something_that_returns_array() { return array( 'a', 'b', 'c', 'd', 'e' ); }
Анника Бэкстрем
2
@DisgruntledGoat: проблема с ()->синтаксисом заключается в том, что он работает только при возврате объекта, что еще хуже, у объекта даже требуется свойство / метод с указанным именем, которое, оптимально, делает то, на что вы надеетесь , принимая параметры, которые вы ему задали, и молясь, чтобы это больше не требовалось ... и т. д. и т. п.
phant0m
72

После работы с 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.

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

Funkatron
источник
(2) посмотрите на runkit. (3) Юникод сложен, особенно потому, что большая часть внешнего мира не является юникодом. Мы должны были бы либо убить производительность, либо потребовать, чтобы люди выполняли много дополнительной работы (как это делает Java). Вот почему php6 unicode не сработал.
StasM
8
Что касается юникода: это может быть сложно, но это было бы чрезвычайно полезно (конечно, разработка самого PHP сложна, но даёт большие преимущества, да?) Возможно, решением было бы включить прозрачный юникод через расширение с понятным компромиссом perf, так же, как XHP? Еще раз спасибо.
Funkatron
5
массив $ object = (object) ("foo" => 'bar', baz => 'boo');
Mercutio
3
Я не понимаю, как вы можете увидеть "большая часть внешнего мира не является Unicode"? Вы говорите о людях? Или что-то другое? Потому что подавляющее большинство людей в мире (с огромным отрывом) говорят на языках, которые лучше всего представлены Unicode.
Дин Хардинг
1
Определенно поддержка Unicode. Доставка любого вида глобально используемого приложения - не стартер без него. Независимо от того, думают ли разработчики PHP о разработке достойной поддержки юникода или нет, это не относится к делу. Людям это нужно, и они разбираются с ошибками платформы, чтобы сделать это. Делфи сделал это, добавив другой тип строки и сделав его по умолчанию, с неявным приведением и глобальным переключателем, чтобы вернуть старое поведение. Почему PHP не может сделать это так же?
Джори Себрехтс
48

Вещи, которые я хотел бы, как бывший давний апологет 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 добавляет перегрузку операторов с помощью магических методов (я знаю, что в принципе этого никогда не произойдет). Но в целом, они предоставляют действительно отличные способы подключиться к языку и делать классные вещи.
davidtbernal
источник
48

Сделайте 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 функций и изменим порядок параметров для них.

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

Keyo
источник
3
Я думаю, что массив, не являющийся типом объекта, является большой ошибкой в ​​PHP. Приводит ко всем видам неприятностей. К сожалению, это эволюционная вещь. Вы можете делать то, что вы хотите здесь с расширением или пользовательским пространством. Вероятно, подойдет SPL хорошо.
StasM
3
Тот же аргумент применяется к строкам. Я просто имею в виду отсутствие методов в целом. Такие языки, как Java, Python, C # и т. Д., Имеют гораздо более читаемый код. Я думаю, вы ищете функции, но исправление того, что сломано IMO, было бы лучше окупить.
Кейо
6
Нет, не будь глупой. Было быdog_wake_up($dog); bark_dog($dog);
Матчу
2
ИМХО, любые новые строковые методы должны ожидать и испускать UTF-8, и генерировать исключения, если входные данные недопустимы в UTF-8. Это значительно уменьшило бы необходимость в переработке поддержки юникода.
rjmunro
1
@luiscubal Нет. Дополнительный параметр будет означать, что мы не сможем добавить параметры позже, если будем изобретать новые вещи для добавления в функцию. Например, если $ string => trim () сделал только пробел (как до 4.1.0), то ваша система скажет, что $ string => trim ('ISO-8859-1') урезал пробел из строк ISO-8859-1 , Если бы мы тогда хотели иметь возможность обрезать то, что не было пробелами, мы не смогли бы добавить параметр для этого, если мы не заставим людей сначала указывать кодировку. Мы должны побуждать людей верить, что любой текст, который не является UTF-8, является неправильным .
rjmunro
40

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

Ник Берарди
источник
2
Все, что облегчает параметризованные запросы, получает мой голос!
Дин Хардинг
1
Я думаю, что стандартизированный доступ к базе данных на самом деле является очень важным преимуществом чего-то вроде LINQ, потому что я думаю, что это облегчает модульное тестирование с имитациями ваших объектов базы данных (так как вы дразните PHP-код вместо SQL-запросов.)
davidtbernal
Я не думаю, что что-то подобное должно войти в ядро. было бы лучше вписаться в расширение
pecl
38

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

Руурд
источник
1
Хотя мне нравится принцип PHP KISS (до некоторой степени), я решительно его поддерживаю. Причина в том, что если вы хотите быть по-настоящему защитным, вы в конечном итоге получите одинаковый код проверки типа в каждом методе установки. Мы могли бы легко отказаться от этого, если бы язык поддерживал это изначально.
MicE
4
«Тип хинтинг» было очень неудачным названием, так как это не «хинтинг», а строгая типизация. Я думаю, что примитивная строгая типизация будет неуместной в динамическом языке, таком как PHP. Принудительная типизация (то же самое, что и внутренние функции - попробуйте strlen (123)) может быть в порядке.
StasM
6
+1 за это. Подсказка типов (или строгая типизация) в объявлениях функций была бы невероятно полезной и сократила бы столько, если (! Is_int ()) дерьмо в КАЖДОМ И КАЖДОМ методе.
Фил Осетрина
5
@ StasM Я не согласен. Он идеально подходит для динамического языка, позволяя пользователю выбирать язык статически типизированным способом. И это позволило бы намного лучше ловить ошибки. Вам бы не пришлось использовать его, если вы этого не хотите, но лично я сыт по горло тем, что строки передаются туда, где я хотел int, а затем приходится искать в коде, чтобы выяснить, куда передается глупая строка Или же, все время проверяйте.
Даниэль Бингхэм
2
@StasM Нет абсолютно никакой причины, по которой вам бы пришлось вводить полностью статически типизированные переменные. Да, вы бы исправили ошибки в вашем коде. Это был бы весь смысл. Ошибка будет возникать во время вызова функции, а не внутри функции, что не позволяет понять, где на самом деле происходит ошибка. Что касается ошибок преобразования типов, то ошибка будет возникать - да, во время выполнения - при вызове функции. Исправьте проблему, преобразовав прямо в правильный тип. Намного лучше, чем строка, появляющаяся в функции, ожидающая int и не знающая откуда.
Даниэль Бингхэм
34

Я действительно желаю лучшей поддержки 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/

Эмиль Стенстрём
источник
Поддержка Unicode оказалась намного сложнее, чем предполагалось. Вот почему усилия php6 были остановлены. На данный момент у нас есть utf-8, и я думаю, что лучше всего было бы добавить поддержку utf-8 для строковых функций, возможно, как часть расширения intl.
StasM
3
Кстати, цитата неверна. Строки PHP являются байтовыми массивами, но их содержимое настолько переносимо, насколько вы их делаете, и не зависит от «кодировки по умолчанию» - это всего лишь массив байтов, вы хотите, чтобы они были в utf8, вставили utf8, хотите utf16 - вставили utf16. Ссылка на phpwact.org кажется мертвой.
StasM
1
Я бы очень надеялся, что расширение intl будет включено по умолчанию, поэтому людям, которым нужен UTF-8 (не все?), Не приходилось бороться со своими хостами, чтобы заставить строковые функции вести себя так, как ожидалось.
Эмиль Стенстрём
Также спасибо за разъяснения по поводу строк. Я был в стороне от PHP некоторое время, поэтому я немного ржавый. Вместо этого я участвовал в войне с юникодом с Python, который имеет те же проблемы, что и PHP, но решает их в Python 3. Наличие шведского «ö» на ваше имя - беспорядок :)
Эмиль Стенстрём,
Это определенно одна из областей, в которой я хотел бы видеть улучшение.
Натан Осман,
32

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

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

и т.п.

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

rjmunro
источник
вверх, это именно то, к чему я стремлюсь.
Kemo
1
subject->verb(object), делает порядок параметров легче запомнить.
Мин-Тан
+1 Я поиграл с созданием своего собственного строкового класса для подобных вещей, это значительно облегчает кодирование, и вы никогда не забудете порядок параметров.
Рассерженная шлюха
2
Так что бы is_object($string)вернуться? Это либо сломало бы обратную совместимость, либо привело бы к введению действительно не интуитивных почти, но не совсем объектов.
Tgr
@Tgr: is_object () не рекомендуется - не должно быть такой вещи, как «не объект». В краткосрочной перспективе это должно быть свойство, которое можно отключить для любого объекта, а конструкторы строк по умолчанию отключат его.
rjmunro
24

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

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

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

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

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

Jakefolio
источник
Я ненавижу создавать create()метод, который не делает ничего особенного только для того, чтобы обойти # 1!
Алан Пирс
Я делаю то же самое, но, используя позднюю статическую привязку и суперкласс объекта, таким образом, каждый класс, который расширяет мой суперкласс, имеет метод, например: SomceClass extends SuperObject {}; SomeClass :: Create () -> SomeMethod ();
Dukeofgaming
Взгляните на github.com/philsturgeon/php-ps. Это только начало, но с некоторой помощью это может быть весьма полезно.
Фил Осетрина
1
Также есть пакет PEAR, который предлагает интерактивную оболочку для быстрого кодирования экспериментов на PHP - доступен по адресу pear.php.net/package/PHP_Shell
kguest
(новый Foo ()) -> bar () является частью 5.4. 3) и 4) тоже.
StasM
20

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

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

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

Подпись,

GrandmasterB

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

GrandmasterB
источник
37
1). Включает это здорово. Все включает в себя. 2). Это хорошо. 3) Шаблонирование - самая сильная особенность PHP . Заставить вас использовать какую-то другую шаблонную фигню было бы очень плохим ходом.
Джош К
8
Мне нравятся (1) и (2), но (3) кажется ретроградным шагом. PHP дает вам силу шаблонов, решать вам, используете ли вы его с умом или нет.
geekbrit
11
3 не имеет смысла - встраивание тегов необходимо для любого V в рамках MVC.
Алекс
9
Я читаю этот ответ как «Дорогой Санта, пожалуйста, сделай так, чтобы PHP не был PHP».
Стивен
1
3 прямо, так как PHP является языком шаблонов.
Андрей
18

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

Анника Бэкстрем
источник
1
Классовые константы делают это, кстати.
StasM
4
Серьезно, я не понимаю, почему они заставляют PHP принимать строки без кавычек. Это самая глупая вещь. Я бы выбрал или E_ERRORили E_PARSE.
BoltClock
14

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

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

Дэвид Мердок
источник
1
Я согласен в принципе, но понятия не имею, как это сделать на практике :)
StasM
3
@StasM: я полагаю, что первым шагом было бы сделать новые версии библиотек пространством имен и позволить программистам (через настройки ini) отключить глобальные библиотеки, которые в настоящее время доступны. Я бы подумал, что пакет совместимости будет для старых версий, но его не должно быть очень сложно написать.
Михал Т
13

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) Я также хотел бы видеть возможность использовать !и ?в именах функций - как Руби может.

Райан Парман
источник
Я согласен, что arrayobject должен поддерживаться для функций array_ *. но каков будет ожидаемый результат для чего-то вроде «array_merge», если вы рассмотрите подклассы arrayobject. Разрешено ли вам только объединять экземпляры одного и того же класса и что вернет array_merge? массив php или экземпляр arrayobject (соответственно это подкласс)?
Харальд
Я бы сказал, что поскольку данные внутренне являются массивом, а ArrayObject объединяет их с функциональностью, то даже подклассы ArrayObject по-прежнему будут работать с массивами внутри. Я ожидал бы возможности объединить другой стандартный массив или ArrayObject (или подкласс). Что касается того, что он будет возвращать, я бы сказал, что он также должен возвращать новый ArrayObject, но следуйте прецеденту, установленному simplexml_load_string (), где вы можете указать имя класса, экземпляром которого должен быть результат.
Райан Парман
12

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' верной

sfrench
источник
2
Я думаю, что (1) что-то приготовленное из итератора и закрытия будет лучше.
StasM
+1 ИМХО, это должно быть включено на всех языках, а также итераторы. Они просто способ полезного не иметь.
Эван Плейс
empty()является логической противоположностью if ($x), поэтому имеет смысл, что empty('0')это правда, потому что if ('0')это ложь. Разница лишь в том, empty()что не выдает уведомление, если переменная не установлена.
Андрей
12

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

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

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

Новая идея!!

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

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

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

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

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

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

Дейв Б.
источник
+1 за final. Чтобы уточнить: finalозначает, что значение переменной может быть установлено во время выполнения (в отличие от констант, которые должны быть константными выражениями), но может быть установлено только один раз. Смотрите также C # readonly.
Давидтбернал
1
есть предложение для геттеров / сеттеров для транка, которые заменят только чтение и т. д. Неизменяемые массивы, хотя, вероятно, будет трудно сделать.
StasM
В phpaccess PHP уже имеет «безопасный режим», который делает то, что вы описываете.
Рассерженная шлюха
11

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

  1. Поддержи наконец. Это большой беспорядок, чтобы вымышленно обойти это с помощью флагов или аналогичных средств.
  2. Я хотел бы видеть поддержку синтаксиса C # для геттеров и сеттеров. Когда у вас много геттеров и сеттеров, простой синтаксис, такой как C #, значительно повышает производительность вместо того, чтобы делать это по-Java и писать методы геттеров и сеттеров. Магические методы хороши в тех случаях, когда вы хотите создавать элементы динамически (например, если вы хотите дать шаблону рендерера некоторые переменные для использования), но они не подходят для обычных свойств, для которых вы хотите, чтобы среда IDE автоматически заполнялась, знайте их типы и тд. это помогло бы сделать код меньше, а читаемым и простым в использовании.
Johnco
источник
1
1. к сожалению, это трудно сделать, но, безусловно, хороший элемент задачи
StasM
@StasM: как насчет аннотаций? Что-то вроде: / ** @get getFoo; @set setFoo; * / private $ foo;
Михал Т
9

Синтаксис языка : в 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>, которая серьезно вредит языку (директориту).

марио
источник
5
Я ненавижу синтаксис \ namespace, но это длинная и грустная история, почему он стал таким и, вероятно, не изменится ... Возможно, если бы я мог изменить только одну вещь в PHP, которая была бы моим основным кандидатом. Но что есть, то есть.
StasM
@StasM: Спасибо за отзыв и извините за грубость в некоторых вещах PHP, но я забочусь о PHP; следовательно, очень самоуверенный. - Я прочитал немного о рассуждениях. Дилемма обратной косой черты еще не очень большая проблема, но она станет следующей в следующем году, когда распространятся библиотеки. Поэтому я надеюсь, что кто-то напишет парсер, который переписывает имена \ cargo \ cult \ class \ names обратно на схемы подчеркивания.
Марио
Может быть, я идиот, но какая разница, используем ли мы «::» или «\» для пространств имен?
Михал Т
@Pies: Это ::было бы более естественным для любого языка, близкого к синтаксису C / C ++. И `\` не только ненормальный среди всех языков программирования, но имеет непроверенную коннотацию. Некоторые предыдущие обсуждения: stackoverflow.com/questions/238550/… or developers.slashdot.org/article.pl?sid=08/10/26/1610259 и reddit.com/r/programming/comments/79cut/… - Но в в частности, принятие решения об этом без обратной связи и сигнал к тому, чтобы сообщество разработчиков смирилось с этим, было не очень желанным шагом.
Марио
1
+ 1000000 за множественное наследование.
01
8

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

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

Alex
источник
1
В движке уже есть поддержка, и многие расширения используют ее. Вы также можете легко сделать это с помощью set_error_handler () и ErrorException. Остерегайтесь E_STRICT / E_NOTICE / E_DEPRECATED хотя ...
StasM
Я хорошо знаю об этих методах, и они действительно хакерские. Я хотел бы унифицированный путь - тот, который включает в себя E_STRICT / E_NOTICE и тому подобное.
Алекс
7

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

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

geekbrit
источник
1
На самом деле, если подумать больше, выгрузка базы данных кажется интересным сценарием, так что +1 на это :)
StasM
1
@Stasm, я предполагаю, что вы имеете в виду, что отдельные запросы выполняются как отдельные процессы. Я говорю о сложной странице, которая требует генерации страниц и фоновых вычислений. Я могу ошибаться, но я не думаю, что есть способ порождать (например) операции обновления базы данных в отдельном процессе. Причиной для этого может быть отправка страницы запрашивающей стороне раньше, а не ожидание завершения всей обработки, не связанной непосредственно с созданием страницы. PS .. Спасибо за обновление!
geekbrit
7

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

pestaa
источник
Да, магические методы для типирования, пожалуйста.
Михал Т
7
  • поддержка перечислений (например, Java 1.5+)
  • Уметь определять типы возвращаемых методов в интерфейсах и классах
  • поддержка аннотаций / определения метаданных о свойствах и методах.
  • уметь делать строгие подсказки типов для скалярных аргументов метода.
Кис ван Диерен
источник
+1 Как я хотел бы видеть все эти вещи в PHP.
Джереми
6

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

bobah
источник
1
Некоторая функциональность голосования вверх / вниз и возможность ссылки на исходный комментарий в ответе, безусловно, были бы хорошими.
Tgr
5

В 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 часто используется для манипулирования структурой данных типа списка, и в этом отношении было бы полезно иметь полный набор инструментов.

Orbling
источник
1
Мой коллега также считает, что могут / должны быть какие-то другие дополнения для функций, связанных с массивами; как упоминалось в его учетной записи на github: Это отсутствие array_all () и array_any (), которые проверяют, выполняется ли * условие, представленное обратным вызовом, для всех или любых элементов в массиве. gist.github.com/44350
kguest
5

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

$result = $MatrixA + $MatrixB * $MatrixC;
Мышей
источник
1
Не уверен, насколько удачно это получится, если PHP является динамически типизированным языком.
BoltClock
5
Может быть, это нужно сделать с помощью магических методов, таких как __add ($ obj), __times ($ obj) и т. Д.
Михал Т
он уже существует как PECL ext: pecl.php.net/package/operator . Не должно быть слишком много работы, чтобы объединить его с основным источником
Xananax
4

Добавлять исключения вместо создания 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» ... Когда я узнал, что это действительно произошло, я подумал, что это был апрельский день дурака.

Eriz
источник
Если не пойман, исключение убьет сценарий. Предупреждение на рабочем сервере регистрируется и никогда не отображается пользователю. Изменение этой функциональности сейчас может привести к поломке многих скриптов, потому что они не предназначены для его перехвата. (Обратите внимание, что я пишу обработчики ошибок, чтобы генерировать исключения самостоятельно). Теперь вещи PDO могут выдавать предупреждения или исключения: программист принимает решение во время выполнения. Эта функциональность, вероятно, должна быть добавлена ​​к большему количеству модулей.
Reece45
4
  1. Объединить объектную модель - заставить все объекты расширять базовый класс объектов. Класс Object будет (среди прочего) реализовывать все магические методы (чтобы они больше не были магическими!)

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

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

оборота Мчл
источник
4

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

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

Дон Макаскилл
источник
4

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

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

мин
источник