11 июня вышла альфа версия долгожданного PHP 7. Этот релиз является началом седьмой ветки. Релиз финальной версии запланирован на ноябрь 2015 года. Под катом приведен неполный список основных нововведений.
- Улучшение быстродействия. PHP 7 работает до двух раз быстрее чем PHP 5.6.
- Добавлена поддержка сокращенной конструкции use:
use Symfony\Component\Console\{ Helper\Table, Question\ChoiceQuestion as Choice, Question\ConfirmationQuestion, };
- Добавлен оператор "??" (Null coalescing operator), позволяющий проверить переменную на существование и вернуть ее значение либо значение по умолчанию.
Например следующая конструкция:
$action = isset($_POST['action']) ? $_POST['action'] : 'index';
Теперь может быть коротко записана так:
$action = $_POST['action'] ?? 'index';
- Добавлена поддержка строк длиной больше 2^31 байт в 64-битных билдах.
- Добавлен метод Closure::call(object $to[, mixed $parameters]), позволяющий вызвать анонимную функцию с произвольным $this.
- Добавлен синтаксис \u{xxxxxx} для строк, позволяющий указывать произвольные Unicode символы в строках.
- В качестве значения констант, объявляемых через define() теперь можно указывать массивы.
- Добавлен новый оператор сравнения <=>, так же известный как «spaceship operator». Конструкция $a <=> $b возвращает -1, 0 или +1 если $a соответственно меньше, равно или больше $b. Удобно использовать в колбэках для usort().
- Зарезервированные ключевые слова теперь можно использовать в качестве имен методов:
$object::new('foo', 'bar')->forEach(function($index, $item) {});
- Синтаксис конструкторов в стиле PHP 4 (имя метода конструктора совпадает с именем класса) теперь считается устаревшим.
- Статичные вызовы (::) нестатичных методов теперь считаются устаревшими.
- Добавлена константа PHP_INT_MIN.
- Удалена INI директива «asp_tags». Попытка включить ее приведет к фатальной ошибке. Так же удалена поддержка тэгов в стиле ASP (<%).
- Удалена INI директива «always_populate_raw_post_data». Переменная $HTTP_RAW_POST_DATA соответственно больше не доступна. Вместо нее используйте дескриптор входного потока php://input.
- Итерация по массиву при помощи foreach() больше не сдвигает внутренний указатель массива, который можно получать и изменять при помощи функций current()/next()/reset() и им подобных. Так же foreach по значению теперь всегда работает с копией массива.
- Оператор левого побитового сдвига (<<) на количество бит, превышающее количество бит в integer теперь всегда возвращает 0. До этого результат зависел от архитектуры процессора. Аналогичный правый сдвиг всегда дает 0 или -1 в зависимости от знака исходного числа (Сдвиг не влияет на старший бит, отвечающий за знак).
- Строки, содержащие шестнадцатеричные числа теперь всегда обрабатываются как строки и не обрабатываются как числа: is_numeric(«0xFF») теперь false, раньше было true со всеми вытекающими.
- Целые числа в 64-х битных билдах для Windows теперь представляются в виде 64-х битных, а не как раньше, 32-х, что делало использование х64 сборок на Windows бессмысленным занятием, если нужны манипуляции с большими числами.
- Удалена поддержка модификатора /e в PCRE. Аналогичная функциональность может быть реализована функцией preg_replace_callback().
- Добавлена поддержка type-hint'ов для скалярных типов. Ранее контроль типов был возможен только для классов, интерфейсов, массивов и типа callable.
- Удалены старые и не поддерживаемые SAPI и расширения.
Более подробный список изменений на английском языке можно найти в указанных источниках:
php.net
github.com/php/php-src/blob/php-7.0.0alpha1/UPGRADING
Комментарии (96)
WaveCut
16.06.2015 12:49+2Не написали очень важное изменение, что PHP для Windows x64 наконец-то начал представлять целые числа в виде 64-х битных, а не как раньше, 32-х, что делало использование х64 сборок на Windows бессмысленным занятием, если нужны манипуляции с большими числами.
dizews
16.06.2015 13:31-2Итерация по массиву при помощи foreach() больше не сдвигает внутренний указатель массива, который можно получать и изменять при помощи функций current()/next()/reset() и им подобных.
Я правильно понимаю что без явного вызова next() цикл будет бесконечным?
Bibainet Автор
16.06.2015 13:37+1Нет, foreach будет работать так же. Просто до этого он так же влиял на положение внутреннего указателя массива, а теперь это как бы две разные вещи.
SilverFire
16.06.2015 13:41+3Нет, скорее:
$array = [1,2,3,4,5]; next($array); var_dump(current($array)); // 2 foreach ($array as $item) { continue; // iterate over array } var_dump(current($array)); // 2. В PHP 5.5 будет FALSE
3v4l.org/nf3Cg
Alexeyco
16.06.2015 14:31Вроде бы нет…
В оригинале есть примеры, которые немного поясняют.
К примеру, если сделать так
$array = [0, 1, 2];
foreach ($array as &$val) {
var_dump(current($array));
}
В php7 три раза выдаст 0. А если убрать амперсанд — отработает как и раньше.
BAV_Lug
16.06.2015 15:57+1Как бы ничего нового глобального я в списке не увидел. Разве что «увеличение производительности» — на что еще тоже нужно будет посмотреть. Кстати, стало интересно, а кто и зачем юзает пых под виндой?
Bibainet Автор
16.06.2015 16:03-2Да и не совсем понятно зачем было перескакивать через 6 версию. Между 5.0 и 5.6 было даже больше изменений в самом языке, но возможно в движке их действительно много. А пых под виндой, для тестов, для разработки, а еще же есть IIS.
BAV_Lug
16.06.2015 16:08Ну для тестов и разработки давно уже многие (как и я) используют виртуалки — после того как несколько раз нарвался на грабли, что под виндой работает, а на продакшене болт. А заводить пых под иис, на мой взгляд, вообще изврат.
FractalizeR
16.06.2015 16:37+4Насколько я помню, это объяснялось тем, что в PHP6 предполагали вводить совсем другие изменения (в частности, родные Unicode-строки). И, как водится, появилось огромное количество книг и статей с названиями типа «Программируем на PHP6», несмотря на то, что изменения даже утверждены еще не были.
Поскольку roadmap сильно изменился, чтобы не вводить в заблуждение пользователей, решили перепрыгнуть через цифру.
lexxpavlov
16.06.2015 16:54>Как бы ничего нового глобального я в списке не увидел
Так это 7.0 заморожен по фичам. А вот в будущих 7.* вполне могут быть новые изменения.
И ещё, очень важного изменения в списке в статье нет — это скалярный type-hint, и это немалая вещь, это серьёзно (хотя в некоторых случаях и не настолько полезно).Bibainet Автор
16.06.2015 17:22Не нашел этого в указанном в источниках документе. Хотя в кратком обзоре это есть. Добавил, спасибо.
Fesor
17.06.2015 02:56Этот список — то что влияет на уже существующий код. То есть маленькие BC-брэйки. Помимо того что полностью переписали все что связано с основными структурами, вот вам кратенький список плюшек нового PHP:
— контекстно зависимый парсер (наконец-то, хоть он всеравно слегка туповат)
— тайп хинтинг для скаляров
— тайп хинтинг для возвращаемых значений
— анонимные классы
— добили генераторы
ну это то что я вспомнил из существенного для меня лично.
wiki.php.net/rfc#php_70 — тут подробнее.
AxisPod
16.06.2015 17:22> Добавлен новый оператор сравнения <=>, так же известный как «spaceship operator». Конструкция $a <=> $b возвращает -1, 0 или +1 если $a соответственно меньше, равно или больше $b. Удобно использовать в колбэках для usort().
Хоть убейте, не понимаю, зачем алгоритму сортировки знать больше, меньше или равно, если достаточно сравнения <. Да и трындеть из всех сил о бардаке в языке, но вместо була вернуть инт, это конечно норм.Alexeyco
16.06.2015 17:44Тогда надо добавить третий вид boolean, чтобы было (как вариант) ложь (-1), истина (0) и правда (1)… кстати, мысль (сарказм).
globik
16.06.2015 18:49+1зачем алгоритму сортировки знать больше, меньше или равно, если достаточно сравнения <
Заинтриговал ваш вопрос, поэтому провел небольшое расследование. Похоже, что сейчас PHP использует свою реализацию алгоритма Quicksort, в котором отдельно не используется информация о равенстве сравниваемых элементов. Но ранее (PHP 4) он использовал стандартную Си функцию qsort из stdlib, которая, в качестве одного из аргументов, как раз принимает функцию сравнения, возвращающую -1,0 или 1.
mjr27
16.06.2015 20:10Надеялся сказать что-то умное, но неожиданно для себя выяснил, что в PHP алгоритмы сортировки неустойчивы.
Так что, видимо, незачем.
meta4
16.06.2015 18:11>Так же foreach по значению теперь всегда работает с копией массива.
Я надеюсь там что-то вроде CoW?
Sanovskiy
16.06.2015 19:09-9Добавлен оператор "??" (Null coalescing operator), позволяющий проверить переменную на существование
Да! Еще больше запутанного говнокода!
В качестве значения констант, объявляемых через define() теперь можно указывать массивы.
facepalm
Синтаксис конструкторов в стиле PHP 4 (имя метода конструктора совпадает с именем класса) теперь считается устаревшим.
ДАНЕУЖЕЛИ!
Удалена INI директива «asp_tags
Это надо было сделать еще в 5.3
Добавлена поддержка type-hint'ов для скалярных типов. Ранее контроль типов был возможен только для классов, интерфейсов, массивов и типа callable.
Единственное, что радует.
И еще: где обещанная строгая типизация?
Blumfontein
16.06.2015 21:45+5Кто вам обещал строгую типизацию?
Sanovskiy
17.06.2015 00:55О ней еще при живой четверке кричали на всех углах.
Мне даже любопытно, кто и за что минусит?Blumfontein
17.06.2015 07:51+2Не будет никогда строгой типизации, потому что динамическая/нестрогая типизация — это ни хорошо и ни плохо, это просто динамическая/нестрогая типизация. Не нравится, есть миллион ЯП со строгой/статической типизацией.
khim
17.06.2015 10:13-2Есть также понимание того, что нестрогая типизация — хороша для сохранения рабочих мест, но плоха, когда хочется написать что-то работающее без ошибок.
Между языками с «динамическая/нестрогая типизацией» и «статической/строгой типизацией» лежат ещё языки с «динамическая/строгой типизацией» (от LIPA до Python'а) и практика показывает, что от нестрогой типизации выигрыша почти никогда нет, зато слёз — куча.
Fesor
17.06.2015 01:25+1где обещанная строгая типизация?
<?php declare(strict_types=1); function foo(string $bar) : string { return $bar . $bar; } foo(123); // error
по умолчанию будет произведен каст (в случае если каст идет с потерями — ошибка), в «строгом» режиме все что не соответствует нужному типу — ошибка.
wiki.php.net/rfc/scalar_type_hints_v5
DjOnline
16.06.2015 23:13>>В качестве значения констант, объявляемых через define() теперь можно указывать массивы.
Только define как был медленным, так и остался, вплоть до того что доступ к массиву по текстовому ключу быстрее чем по константе define. Писал об этом ранее habrahabr.ru/post/257237/#comment_8415927
bBars
17.06.2015 01:50Type-хинты радуют. Не знал о том, что можно было указывать на callable. Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?
Прямо сегодня столкнулся с тем, что shr не трогает старший бит. Зачем так сделали? Неужто все эту операцию только для деления на 2 используют?
Fesor
17.06.2015 02:48+1Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?
Читаем документацию. Все что валидно для call_user_func.
Еще интересная штука, которая появилась в PHP7 но о чем не написано в статье (она написана на базе информации для обновления, новых фич тут как бы и не описано вовсе) — анонимные классы. То есть теперь можно упарываться почти как в java для описания колбэков, реализующих интерфейсы:
<?php interface FooCallback { public function __call(string $foo, string $bar) : string; } function foo(FooCallback $foo) : string { return $foo('foo', 'bar'); } foo(new class implements FooCallback { public function __call(string $foo, string $bar) : string { return $foo . $bar; } });
что-то в этом духе.
wiki.php.net/rfc/anonymous_classes
sevka_fedoroff
17.06.2015 11:36Люди, а объясните, что значит «Так же foreach по значению теперь всегда работает с копией массива»?
Bibainet Автор
17.06.2015 13:32В теле цикла foreach теперь не получится производить манипуляции над самим массивом.
felicast
17.06.2015 14:01Как я понял, наоборот, можно менять оригинальный массив, но foreach будет идти по старому, не измененному.
Fesor
17.06.2015 14:07Да, при передаче массива в foreach теперь происходит копирование (как при передаче аргументов функции). Естественно Copy-on-write никто не отменял и если вы не меняли массив в цикле то реально копирование происходить не будет.
sevka_fedoroff
17.06.2015 14:11+1foreach($a as $k => $v) { $a[k] = $v+1; }
После этого изменится массив $a?sevka_fedoroff
17.06.2015 16:08Сам отвечу на свой вопрос. Судя по wiki.php.net/rfc/php7_foreach, массив $a изменится после завершения цикла (как и сейчас в ПХП5).
А речь вообще о другом. А именно, о том, как ведет себя текущий перебор массива в цикле foreach в том случае, если внутри цикла происходит модификация этого массива.
Сейчас в некоторых ситуациях поведение довольно странное. В ПХП7 хотят это поведение сделать предсказуемым.
Bibainet Автор
17.06.2015 14:22+1Но даже сейчас, в 5.6, если в теле цикла добавить элемент в массив, цикл его не затронет. Если изменить элемент, то цикл все равно получает неизмененное значение. Вот пример с пояснениями:
$a = [0, 1, 2]; foreach ($a as $item) { if ($item === 1) { $a[2] = 3; // Изменяем следующий элемент $a[] = 4; // Добавляем элемент в конец // $a теперь равно [0, 1, 3, 4], но цикл по прежнему выдает 0, 1, 2. }; echo $item, ' '; }; print_r($a);
Результат:
0 1 2 Array
(
[0] => 0
[1] => 1
[2] => 3
[3] => 4
)sevka_fedoroff
17.06.2015 14:27Да, так и есть. Вот я и не могу понять, что значит «foreach по значению теперь всегда работает с копией массива»
Вроде как он и в 5.х работает с копией. Тут некоторые говорят, что вообще нельзя будет в теле foreach производить манипуляции типа $a[1] = 2. По-моему это странно.
reket
17.06.2015 15:25Похоже речь идет об этом wiki.php.net/rfc/php7_foreach (там подробно с примерами).
gro
17.06.2015 12:04Двадцать раз уже на хабре написано, что нового в PHP 7.
Написали бы конкретно, какие в альфе нюансы.
clockworkbird
10.07.2015 09:03Конечно все замечательно, но такими темпами язык все больше и больше отстает от жизни.
Fesor
10.07.2015 09:24Можно как-то аргументировать?
clockworkbird
10.07.2015 11:23Ну, во первых, на мажорную версию такой список совсем не тянет.
Конечно, на самом деле, изменения глобальнее, но все равно.
Давно пора уже самому языку стать объектным.
Понятно, что обратная совместимость и куча стона «не ломайте наш язык» и мегатонны кода, но хотя бы с возможностью переключателя (для тех, кому хочется). Сообщество огромно и необходимый код, уверен, мигрировал бы на новый синтаксис достаточно быстро.
А так — это топтание в болоте.
Итак у языка репутация уже ниже плинтуса.Bibainet Автор
10.07.2015 12:18По поводу мажорной версии, в статье описаны только изменения самого языка, но есть еще очень много существенных изменений в ядре.
По поводу сделать объектным сам язык — это был бы уже совсем другой язык и другая история. А может быть когда нибудь будет.clockworkbird
10.07.2015 14:25Мне кажется, вопрос, как раз и в этом — назрело уже. Либо меняешься, либо умираешь.
Объекты в языке же появились в связи с развитием программирования — ничего страшного с языком и его популярностью не случилось, только лучше для всех стало.khim
10.07.2015 14:32С популярностью ничего не стало потому что все эти новомодности типа объектов можно тупо игнорировать — и при этом свои поделки как-то таки прождать. Если у PHP отнять это свойство и сделать так, что для использования языка его придётся изучать, то кому он такой будет нужен? Вы же убьёте единственное его достоинство — возможность программирования с помощью применения генетических алгоритмов к ответам на Stack Overflow без задействования головного мозга!
clockworkbird
10.07.2015 14:37Да через Stack Overflow будут уже новый синтаксис копировать — делов то )
khim
10.07.2015 16:06А кто старый оттуда изведёт и, главное, породить тысячи нового? Посмотрите на python — там вроде публика чуть больше думать приучена, а невозможность использования старого кода обозначает, что за многие годы, прошедшие с выхода python 3 на него пересели единицы.
Убирать из языка можно только то, что уже почти никто не использует, да и то с осторожностью, это ещё разработчики FORTRAN'а выяснили, когда попытались несколько фич выкинуть в FORTRAN 77!clockworkbird
10.07.2015 16:36Убирать не обязательно. Сделать параллельный синтаксис и опциональную возможность отключения в php.ini старого.
Надо же что-то с этим делать.
Миграция кода — не проблема в наше время.Fesor
10.07.2015 17:06Миграция кода — не проблема в наше время.
я бы хотел жить в вашем времени.
Сделать параллельный синтаксис
Сколько там чуваки мигрировали с Python2 на Python3?khim
10.07.2015 18:26+1
А причём тут Python? Как раз там никакого параллельного синтаксиса никто не сделал: вы не можете ни включить в проект на Python2 модуль написанный для Python3, ни наоборот.Сделать параллельный синтаксис
Сколько там чуваки мигрировали с Python2 на Python3?
Тут скорее нужно как раз на тот же FORTRAN смотреть, только на FORTRAN 90. Он как раз предложил новый синтаксис, в котором не нужно считать колонки — и им даже многие начали пользоваться. А многие (хорошо если не большинство) — по прежнему используют fixed form! А уж найти хоть одного программиста, который бы на фортране или коболе писал бы объектно-ориентированные программы мне не удалось. Хотя оба языка поддерживают OOP уже многие годы.
Я думаю разработчики PHP просто здраво оценивают свои силы и считают, что «два языка в одном» они просто не потянут. Особенно с учётом того, какие прелести могут ожидать их «на стыках».
Fesor
10.07.2015 12:27То что приведено в статье это далеко не полный список изменений и плюшек.
Давно пора уже самому языку стать объектным.
Тип все что вам нужно для счастья это что бы инты были объектами? И что вы будете делать? Наследоваться от интов? Примешивать поведение вы всеравно не сможете (во всяком случае пока, и я думаю это была бы опасная вещь в руках по-ха-пэшников).
Если только с точки зрения синтаксиса — раньше у PHP был крайне неуклюжий парсер и это сделать было просто невозможно. С 7-ой версии там уже нормальный парсер, даже местами контекстно зависимый и заимплементить это дело в принципе уже можно. Не превращать скаляры в объекты а просто синтаксис сделать схожий. Так же есть предпосылки для более глубоких оптимизаций на уровне генерации опкодов, аля алиасы для функций которые просто вызывают php-шные функции не будут добавлять оверхэда вообще, потому как на уровне опкодов мы не будем дергать лишние функции. А это значит что можно будет вместо резкого перехода сделать полифилы, шимы и т.д. которые и на производительность сильно влиять не будут и помогут проще перейти на новый синтаксис или просто добавить вариант использования.
Итак у языка репутация уже ниже плинтуса.
Она ниже плинтуса не потому что язык плохой, я бы так не сказал, а потому что любой идиот может на нем что-то написать. Именно по этому в PHP комьюнити так много индусов и быдла. Скажем возьми человек Python или Ruby ему придется чутка побиться головой и почитать документацию. А с PHP берешь и кодишь всякий треш, и мнишь себя гением. И добрая половина просто не считает необходимым развиваться куда-то дальше начального уровня. Таких людей хватает и в Ruby и Python сообществе, но процент сильно меньше, так как в самом начала всеравно придется чуть чуть поднапрячься. А затем кривая обучения идет примерно одинаково, По количеству же толковых разработчиков я думаю разницы особо нет.clockworkbird
10.07.2015 13:54Тип все что вам нужно для счастья это что бы инты были объектами?
Ну спагети-код из объектных вызовов библиотек и функций раздражает, да.
Но не только вызовы. Сама реализация функций хромает что не возьми. Плюс динамическая типизация (понятно, что никуда уже от этого не деться) доставляет хлопот больше, чем дает преимуществ.
А будь все объектно, стабильно и единообразно, так глядишь и быдлокодеры подтянулись бы по качеству.
Она ниже плинтуса не потому что язык плохой, я бы так не сказал, а потому что любой идиот может на нем что-то написать.
Да нет, не от того, что пишут плохо. Это в любом языке можно сделать. Мы вот пишем и на Ruby и на PHP — что ж мы на Ruby специально пишем хорошо, а на PHP плохо? )
А все из-за того, что синтаксис нелогичный, груз обратной совместимости, реализация функций с багами (да, конечно, тянется из сишных библиотек, но от этого не легче).
От того, что в языке нет никакой системы пакетов и расширений (не для самого языка — для проектов на нем) — приходилось копипастить, отсюда и быдлокодерство.
Отчего тот же композер не зашить в сам язык? Почему нельзя сделать сборку языка с библиотеками попроектной — в самом языке?
От того, что системно язык не организован — невозможно поставить произвольную версию под проект, не говоря уже про несколько версий одновременно (да, есть phpbrew, но попробуйте с ним построить нормальный продакшн — проще уж виртуализировать),…
Аналоги инструментов появляются, все-таки опенсорс великая штука, но все они всегда хуже конкурирующих продуктов других языков. В основном, за счет организации как раз самого языка.
Единственная и последняя опора PHP — виртуальный хостинг — возможность размещать проекты на нем на хостинге за $5 в год без необходимости иметь хоть какого-то сисадмина. В этой нише с PHP пока не может полноценно конкурировать ни один язык, поэтому PHP и остается пока лидером.
Конечно вопросы решаются и объекты какие-никакие появились, и нэймспэйсы, но все надо оценивать в сравнении.
По сравнении с конкурирующими технологиями PHP огромными скачками несется в прошлое — с каждым днем «отстает от поезда» все больше и больше.khim
10.07.2015 14:25А будь все объектно, стабильно и единообразно, так глядишь и быдлокодеры подтянулись бы по качеству.
Неа. Ушли бы куда-нибудь на другой язык.
Да нет, не от того, что пишут плохо. Это в любом языке можно сделать. Мы вот пишем и на Ruby и на PHP — что ж мы на Ruby специально пишем хорошо, а на PHP плохо? )
Да. Естественный отбор, однако. Достоинство PHP является прямой причиной всех его недостатков: он был задуман так, чтобы человек, ничего не знающий о программировании, смог бы сделать работающую программу. Конечно в ней будет куча косяков, но она будет работать! А значит её можно отдать заказчику и пойти делать следующий сайт за 5 копеек.
По сравнении с конкурирующими технологиями PHP огромными скачками несется в прошлое — с каждым днем «отстает от поезда» все больше и больше.
Никуда он не отстаёт. Свою нишу (язык для людей, которые либо не могут либо не хотят научиться грамотно программировать) он занимает прочно, а никакую другую ему занять не светит, так как их уже давно заняли другие, более аккуратно сделанные языки.clockworkbird
10.07.2015 14:30Неа. Ушли бы куда-нибудь на другой язык.
Зачем? Если сам язык позволял бы легко и просто, без танцев с бубнами, писать чистый код — просто результат был бы другим.
Никуда он не отстаёт. Свою нишу (язык для людей, которые либо не могут либо не хотят научиться грамотно программировать) он занимает прочно, а никакую другую ему занять не светит, так как их уже давно заняли другие, более аккуратно сделанные языки.
Только за счет возможности работы на дешевом виртаульном хостинге. Это последнее конкурентное преимущество.
Т.к. количество кода в наше время уже не является преимуществом.
Помню, как в свое время говорили, что у Windows Mobile огромное конкурентное преимущество за счет огромного количества написанного кода, а через год все работало уже под андроидом и ios и про WM никто уже даже и не вспоминал.
Посмотрите количество гемов под рельсы и сравните с любыми модулями и бандлами для PHP-фреймворков.khim
10.07.2015 18:19
Затем что кушать что-то хочется, да.Неа. Ушли бы куда-нибудь на другой язык.
Зачем?
Поймите вы: если человек понимает почему, скажем, в python'е (просто пример приличного языка, который я хорошо знаю)"10" < "5"— этоTrue,10 < 5— этоFalse, а"10" < 5— это вообщеTypeError(исключение, которое, если его не поймать, обрушит всю программу), то ему, конечно, хочется от языка некоторой стройности.
Но подавляющее большинство людей этого не понимают и понимать не хотят. А говнокодить-то хочется.
И вот для них сейчас PHP — лучший выбор. А поскольку их — гораздо больше, чем программистов на многих других языках, то и разработчики библиотек и расширений (которые, в большинстве своём, всё-таки способны такие вещи понять, да и вообще — программировать-то умеют) без работы не сидят.
А если вы измените PHP так, что им невозможно будет пользоваться людям, которые не умеют программировать, то вся экосистема развалится.
Посмотрите количество гемов под рельсы и сравните с любыми модулями и бандлами для PHP-фреймворков.
А вы лучше посмотрите на количество сайтов на которых что-то такие крутится на основе WordPress'а (или, ещё того хуже, phpBB). Ни о каких гемах их разработчики (в большинстве своём) даже не мечтают!
PHP — это VisualBasic наших дней. Когда Microsoft решил «осовременить» Visial Basic и предложил программирующим на нём (которые в те времена составляли чуть ли не половину вообще всех людей, которые что-то там программировали) VisualBasic.NET со всякими новомодными плюшками, но люди их «ниасилили». Кто-то переключился на PHP, кто-то переквалифицировался в VBA-программистов, кто-то «закусил удила» и выучил-таки C#, но разбежались в разных направлениях почти все. Вся экосистема была уничтожена почти под корень за считанные годы.
Помню, как в свое время говорили, что у Windows Mobile огромное конкурентное преимущество за счет огромного количества написанного кода, а через год все работало уже под андроидом и ios и про WM никто уже даже и не вспоминал.
Дык правильно говорили. Во-первых через год ничего почти не работало (это я вам как человек, ходящий с Android'ом с 2008го года говорю). А во-вторых — это пример вообще не из той оперы: первые несколько лет много людей по прежнему пользовались телефонами на Windows Mobile и Symbian'е, так как под них нужный им софт был, а больше ни подо что не было, а потом Microsoft удавил сначала Windows Mobile (Windows Phone 7 использовал ядро от Windows Mobile, но старые программы использовать было нельзя), а потом внедрил своего засланного казачка в Nokia и Symbian тоже удавил. Разумеется если платформу насильственным образом убили, то количество софта под неё уже никакой роли играть не может!
У меня вообще есть ощущение, что весь проект Windows Phone (и особенно — с привлечением Nokia) был задуман и осуществлён как грандиозная диверсия. Потому что даже если кто-то решил бы специально уничтожить всех реальных конкурентов Android'у, то ничего лучше было придумать просто нельзя.
neolink
10.07.2015 12:48> но процент сильно меньше
не факт, я видел много людей которые делали треш на ruby, java, c#. тут ещё общее кол-во вовлеченных влияет. как не крути а php популярен.
но вообще clockworkbird года на 2-3 опоздал с «топтанием». по поводу объектности языка не оч. понятно что имелось ввиду. да вы бы первый и плевались от этой объектности — когда $a->round(2) падает так как вы не сделали кастинг в int.
и кстати в 7 есть и переключатели для пары фич.clockworkbird
10.07.2015 14:04Да не я опоздал, а PHP походу )
Я с 3 версии работаю (после perl это был глоток свежего воздуха), а с 5 версии все жду — когда же, когда. Шестого не будет, ну ладно, ну в 7 то уже точно… Ага, щас — __constructor отменили, все дела.
Уже и с любимого PHP на Ruby переполз местами, уже заказчики в ответ на предложение сделать проект на PHP-фреймворке пишут: «Опять ты мне какое-то г@#$о прелагаешь»,… и чувствую — не дождусь.
MaximChistov
>оператор ??
Побыстрее бы его в Java/C# ввели, очень удобная штуковина :)
Quetzal
Эм, как бы в C# он уже есть (см. Null coalescing operator)
difiso
C#:
MaximChistov
класс :)
java как всегда не торопится )
Borz
в Groovy есть Elvis-оператор "?:"
avolver
В текущем php (5.6) есть возможность использовать тернарный оператор без второго операнда, что позволяет уже создавать аналогичные конструкции вида:
MaximChistov
а если в $_POST['action'] будет false?)
все-таки основной смысл ?? в обработке null, что больше проблема компилируемых языков
Bibainet Автор
А если $_POST['action'] не существует, то вообще будет notice.
marapper
Проблема в isset.
Opik
Только вот будет notice, если в посте нет action
falke2
Разве что так, чтобы без нотайса:
Bibainet Автор
Тут уже отвечали, что там может быть false, 0, «0», пустой массив. И эти значения будут проигнорированы. В любом случае здесь будет ошибка, а ошибки лучше не глушить, а избегать. Тем более @ — затратный оператор, он устанавливает error_reporting в 0 перед вычислением выражения.