Які функції ви хотіли б мати в 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 років, і близько 4 років з JS, є кілька речей, на які я думаю, що PHP добре би запозичив JS:

1) скорочення позначень для масивів та об'єктів. Я вважаю, що це, можливо, було обговорено і збито в "Інтернеті" (тому я чую - мені не подобається бачити, як робиться ковбаса), але я дійсно, дійсно вважаю, що буквальне позначення масивів та об'єктів у 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';

Я чув, що було викликано занепокоєння щодо потенційної плутанини, але насправді, чи це більше заплутаність, ніж, скажімо, позначення гередока? Принаймні, зробити об’єкт stdClass в PHP достатньо багатослівний, щоб відмовити практиці, я думаю.

2) Бути в змозі перевизначити раніше визначені функції та методи було б дуже корисно. Зокрема, це спростить ситуації, що розширюють клас, а інстанціювання нового класу є надмірно складним або непрактичним. Я думаю, що нам слід уникати переосмислення основних та непростірних функцій та методів простору користувачів.

Крім цих двох, я думаю, що PHP повинен прозоро підтримувати unicode . Це стає дедалі більшою проблемою для розробників, і рішення, які зараз пропонуються в PHP, є заплутаними та часто невиконаними. Зробити всі стандартні функціональні функції рядків непридатними для коду, було б величезною виграшею для програмістів 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 (string) не мають поняття про 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) Якщо ви коли-небудь користувались рубіном та останнім часом вузлом, у них є чудова інтерактивна оболонка (IRB). Я хотів би, щоб PHP мав такий, який був насправді корисний.

3) Риси / Міксини, але я чую, що вони в дорозі.

4) я хочу вторити короткий масив $ myArray = ['мій', 'масив'];

5) Послідовне найменування / порядок (тобто голка стога сіна)

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

2) Будь ласка, надайте нестандартний спосіб компіляції програми PHP в єдиний розподільний файл байтового коду або виконуваний файл. Це значно підвищить привабливість PHP як комерційної мови розвитку. Це має бути базовим компонентом мови. Не хвилюйтесь про HTML-файли, які використовуються для GUI програми, тому що ...

3) будь ласка, позбудьтесь можливості вбудовувати теги PHP у HTML. Або хоча б забезпечити режим "без вбудовування". Це абсолютний безлад і заохочує поганий дизайн, змішуючи логіку програми та презентацію разом. Розробники повинні використовувати шаблони для відображення, а не плескати файли PHP разом і сподіватися на найкраще.

Підписано,

ГрандмайстерB

ps: не слухайте, що тут говорять інші, мені було приємно весь рік

Ini директива E_ERRORщодо невизначених констант, а не припускати, що це рядок із E_NOTICE.

Нормалізуйте глобальний простір імен за допомогою продуманої конвенції про іменування, яка має сенс для новачків!

Цитувати нашого улюбленого Джеффа Етвуда: PHP смокче, але це не має значення !

Струни повинні бути об’єктами

1) Коротший синтаксис масиву / об’єкта, a la 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. Замість старовинних ниток, було б непогано щось на зразок Apple Grand Central Dispatch. Або навіть щось схоже на JavaScript, де ви можете робити запити асинхронізації та визначати зворотні дзвінки.

10) Послідовне називання / порядок (тобто голковий стог) було б непогано, але я думаю, що це можна було б краще вирішити за допомогою SPL.

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

12) Для API Reflection додайте підтримку коментарів (a) docblock на константи (глобальний та клас) та (b) підтримку для розбору коментарів, схожих на PHPDoc, у розумну структуру даних. Є пакет PECL під назвою "docblock", який намагається це зробити, але не здається, що автор зайшов дуже далеко.

EDIT: 13) Я також хотів би бачити можливість використання !та ?в назвах функцій - як Ruby can.

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) Зробіть порожнім (), не вважайте рядок "0" істинним

Я хотів би бачити законний метод створення / визначення масивів CONSTANT. Існує кілька шахрайських способів імітувати такий функціонал, але було б непогано, якби це була просто пряма особливість PHP. Було б добре, якби ви могли створити масив таким чином, який схожий на "остаточне" оголошення Java.

Я створив систему входу, яку дуже швидко налаштувати. Все, що вам потрібно зробити - це змінити вміст масиву в текстовому файлі, щоб вказати потрібні поля для інформації про користувача. Використовуючи низку циклів, вона обробляє все, починаючи з генерації форми та сенсибілізації введення, до викликів бази даних, але все залежить від цього вихідного масиву.

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

Нова ідея !!

Ох, я придумав щось інше, що мені б дуже хотілося в php. Мені б хотілося, щоб якась система контролювала операції з файловими файлами PHP та операціями з каталогами, аналогічно тому, як працює .htaccess.

Файл .phpaccess повинен викликати якусь ту саму політику домену / тієї самої джерела.

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

Я думаю, що така система зробить віртуальний хостинг набагато безпечнішим середовищем. Якщо ви можете розмістити одну з них у верхній частині кожного віртуального хоста, це зменшить шанс того, що хтось знайде спосіб проникнути у сусіднього віртуального хоста.

Крім того, якщо було б добре мати спосіб її закріплення в зворотному порядку. тобто обмеження досяжності скриптів в одному каталозі до цього каталогу.

Його інь і янь знаєте!

Мої два найбільші побажання як хардкор PHP-програміста:

1. Підтримка нарешті. Великий безлад вимислено обійти це через прапори чи подібні засоби.
2. Я хотів би побачити підтримку в синтаксисі C # для геттерів та сеттерів. Коли у вас є багато геттерів і сеттерів, простий синтаксис, такий як C # 's, - це чудовий підсилювач продуктивності, а не робити це способом 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, скорочена система була б чудовою, особливо, коли мова йде про команди / зменшення команд.

Що ще важливіше, перелік функцій не зовсім завершений:

• немає 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();
}

Звичайно, наразі це не так вже й практично, але отримувати:

УВАГА

УВАГА

УВАГА

і я не можу контролювати потік коду, не записуючи власний error_handler та рядкове обнюхування, яка була створена помилка (дозвіл, неправильне ім'я файлу чи щось інше; я не заперечую про інші джерела помилок тут), щоб викинути правильне виключення .

Я сподіваюся, що не маю пояснити, чому це важливо.

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, змусивши людей правильно кодувати.