Представлен (http://php.net/index.php#id2014-08-28-1) новый значительный релиз языка программирования PHP 5.6.0 (http://php.net/). В версии PHP 5.6.0 добавлены константные скалярные выражения, функции с переменным числом аргументов, импорт функций и констант при помощи оператора use, оператор возведения в степень, интерактивный отладчик phpdbg. Следующим шагом развития языка PHP станет воплощение идей по существенному увеличению производительности движка Zend Engine и изменению методов работы с памятью, развиваемых (http://www.opennet.me/opennews/art.shtml?num=39724) в рамках экспериментальной ветки PHPNG.Ключевые новшества (http://ru2.php.net/migration56.new-features):
- Константные скалярные выражения (constant scalar expressions), допускающие применение операций над числовыми или строковыми литералами и константами в контексте, предусмотренном для статических значений, таком как определение констант или значений по умолчанию аргументов функций. Например, "const ONE = 1; const TWO = ONE + 2;"
- Функции с переменным числом аргументов (Variadic function (http://en.wikipedia.org/wiki/Variadic_functions)), при определении которых явно не указывается число передаваемых аргументов. Например, функцию "function f($req, $opt = null, ...$params)" можно вызывать как f(1, 2), f(1, 2, 3, 4, 5) и т.п., где $req является обязательным аргументом, $opt - опциональным, а все дополнительные аргументы передаются в форме массива $params.
- Распаковка массивов или перечисляемых объектов в вид набора аргументов при вызове функции, используя оператор "...". Например, "$operators = [2, 3]; echo add(1, ...$operators);", где add является функцией трёх аргументов;
- Возможность использования оператора use для импорта функций и констант, в дополнение к импорту классов. Например, "namespace { use function Name\Space\f;...." для импорта в текущее пространство имён функции f, определённой в пространстве имён Name\Space;
- Новый интерактивный отладчик phpdbg (http://phpdbg.com/docs), выполненный в форме модуля SAPI;
- Возможность повторного использования ввода php://input, который теперь может быть переоткрыт и прочитан более одного раза. Изменение также привело к значительному сокращению потребления памяти при обработке данных, переданных через метод POST. Переменная $HTTP_RAW_POST_DATA причислена к устаревшим возможностям;
- Для объектов GMP (http://docs.php.net/manual/en/book.gmp.php) обеспечена возможность перегрузки оператора и приведения скалярных типов;- Поддержка загрузки файлов размером больше 2GiB;
- Добавлен новый математический оператор "**", применяемый для возведения в степень. Например, "$a ** $b" - возвести $a в степень $b;
- Улучшение поддержки SSL/TLS. В частности, в расширении OpenSSL добавлена возможность извлечения и проверки подписи (fingerprint) сертификатов. Для извлечения подписи из сертификатов X.509 добавлена функция openssl_x509_fingerprint(). Для SSL-потоков добавлены две контекстные опции: capture_peer_cert для захвата сертификата X.509 и peer_fingerprint для проверки его соответствия заданной подписи. Кроме того, добавлена поддержка выбора криптографических методов, таких как SSLv3 и TLS, через установку контекстной опции crypto_method, поддерживающей значения STREAM_CRYPTO_METHOD_SSLv2_CLIENT, STREAM_CRYPTO_METHOD_SSLv3_CLIENT, STREAM_CRYPTO_METHOD_SSLv23_CLIENT (по умолчанию) и STREAM_CRYPTO_METHOD_TLS_CLIENT;- Поддержка алгоритма хэширования gost-crypto;
- Добавлен новый скрытый метод __debugInfo(), предоставляющий дополнительную отладочную информацию для объекта;
- В FPM SAPI реализована опция конфигурации clear_env для очистки переменных окружения;
- Новые функции hash_equals( (http://ru2.php.net/manual/en/function.hash-equals.php)) и opcache_is_script_cached();
- Упрощена обработка кодировки на выходе через использование в качестве кодировки по умолчанию значения default_charset;
- В расширение mysqlnd добавлен новый метод извлечения данных, примечательный меньшим потреблением памяти за счёт большего числа операций копирования блоков памяти;
- В расширение PCRE добавлена поддержка маркеров (http://grokbase.com/t/php/php-internals/142wrqvs7p/add-suppo...
- В расширение Pgsql добавлена поддержка выполнения запросов и соединений в асинхронном режиме;
- Изменения, нарушающие совместимость:
- Ключи массива не могут быть перезаписаны при определении массива в качестве свойства класса с использованием литерала array;
- Обеспечена более строгая проверка синтаксиса JSON в функции json_decode();
- Обвязки для потоков теперь по умолчанию выполняют верификацию сертификата и имени хоста пира при использовании SSL/TLS;
- Все ресурсы GMP теперь являются объектами;
- Расширение mcrypt (http://ru2.php.net/manual/en/book.mcrypt.php) теперь требует указания корректных ключей и векторов инициализации.URL: http://php.net/index.php#id2014-08-28-1
Новость: http://www.opennet.me/opennews/art.shtml?num=40480
уверены насчет "const ONE = 1; const TWO = ONE + 2;"
т.к. TWO тогда будет 3 )))
И в таких вот примерах программирования на PHP все интернеты...
Всё верно. В новой версии TWO == 3.
Между тем, в http://ru2.php.net/migration56.new-features этот, безусловно, волнующий фрагмент кода написан какconst ONE = 1;
const TWO = ONE * 2;
> Поддержка алгоритма хэширования gost-cryptoэто должно быть в самом языке?
>> Поддержка алгоритма хэширования gost-crypto
> это должно быть в самом языке?Why not? Мне кажется чем больше стандартизовано на уровне языка (только нормально, с какими-то конвенциями всё-таки, а не так, что у решающих совершенно аналогичные задачи функций разные порядки аргументов и т.п.) - тем лучше - меньше простор для "велоспорта", меньше "самобытности" и "неповторимого стиля" в разных программах, лучше портируемость программ.
Не в языке, а в стандартной библиотеке. Почему бы и нет?
Это же пых, там все либы засунуты в язык.
>> mysqlnd добавлен новый метод извлечения данных, примечательный меньшим потреблением памяти за счёт большего числа операций копирования блоков памяти;Месье знает толк
Не уточните, что вас смущает?
Вместо выделения буферов и копирования можно было реализовать указатель на память
Менее производительно
Реализация блокировок на многоядерных системах?
> "function f($req, $opt = null, ...$params)"
> все дополнительные аргументы передаются в форме массива $params.Ага. Они научились передавать дополнительные аргументы в виде списка при использовании специальной конструкции. Почему мне это напоминает точку?
> используя оператор "...". Например, "$operators = [2, 3]; echo add(1, ...$operators);", где add является функцией трёх аргументов;
Ого. А ещё они научились разворачивать списки. Почему мне это напоминает запятую? (Окей, не придирайтесь - ,@)
Может быть подбросить разработчиком PHP книжку какую... SICP, например, или PCL? Они там ещё много идей почерпнут.
> Возможность использования оператора use для импорта функций и констант, в дополнение к импорту классов.
Просветлятся, например, как require реализовывать надо...
Судя по коммитам в мастер (он же php7), книжки недавно почитали. Например, вместо бизоновских регулярок, плюющихся опкодами на лету как попало, сделали AST.Лет через 5, кажись, будет что-то похожее на настоящее.
Раньше. 7 планируют через пару лет, и он уже точно будет включать Uniform Variable Syntax, phpng-оптимизации, AST.
> Судя по коммитам в мастер (он же php7), книжки недавно почитали. Например,
> вместо бизоновских регулярок, плюющихся опкодами на лету как попало, сделали AST.
> Лет через 5, кажись, будет что-то похожее на настоящее.Через пять лет тя кремируют уже.
Можно вообще-то вспомнить Perl, на котором php основывался и в котором все это было пару десятилетий назад.
Годы идут, а по-прежнему NULL < -1, NULL == 0, "666" == "0666", "1e3" == "1000", а деление на ноль - warning.Прочие WTF'ы не проверял, но уверен, что они на месте.
Спасибо, ещё несколько примеров того, почему php – плохой язык.
Пожалуйста, http://habrahabr.ru/post/142140/.
Я конечно с вами согласен что php ужасен. Чего только стоит function foo($x, $x){//...} Но все-же справедливости ради стоит отметить что половина того что там написано уже не актуально.
Как же вы задрали со своим фракталом.
Что есть, то есть, товарищ.
А как люди живут со всем этим? Вот как, например, проверить строку на равенство "1e3" и неравенство "1000"? Или, более жизненно, численную переменную, что она равна нулю, но не NULL?
Очевидно, использовать тройное равенство. Оно исключает приведение типов.>Вот как, например, проверить строку на равенство "1e3" и неравенство "1000"?
$a === '1e3'; $b !== '1e3'
>Или, более жизненно, численную переменную, что она равна нулю, но не NULL?$c === 0
> Очевидно, использовать тройное равенство. Оно исключает приведение типов.Тогда в чём проблема?
Ну обкакать же пых хочется. А тут такая возможность - дёшево и сердито
use ===, Luke.php > var_dump(0 === NULL);
bool(false)
php > var_dump(0 == NULL);
bool(true)
php > var_dump(1e3 === 1000);
bool(false)
php > var_dump(1e3 == 1000);
bool(true)
> Прочие WTF'ы не проверял, но уверен, что они на месте.Я вам помогу: http://php.net/manual/en/types.comparisons.php
Но, как уже отметили выше, большинство этих проблем решаются строгим сравнением.
Как строгое сравнение поможет с первыми двумя проблемами, делающими результат сортировки массива зависящим от порядка сравнения элементов?
Я сказал "большинство проблем", а не "все".
Если вас не устраивает результат при сравнении целого с null, то можете определить какое-угодно поведение, благо проверить тип переменной не составляет труда.
> то можете определить какое-угодно поведение, благо проверить тип переменной не составляет труда.Как это поможет исправить проблему, связанную с тем, что сортировка массива встроенными средствами возвращает разные результаты в зависимости от порядка элементов? Вот вам пример. Даны три массива с одними и теми же элементами в разном порядке. Сортируем их и получаем на выходе типичный пыхапизм.
$ cat a.php
<?php$a = array(1,-1,0,NULL,2,0,-2);
$b = array(NULL,-1,0,1,2,-2, 0);
$c = array(0,1,-1,0,-2,2,NULL);echo "asort(array(1,-1,0,NULL,2,0,-2))\n";
asort($a);
print_r($a);
echo "\nasort(array(NULL,-1,0,1,2,-2, 0))\n";
asort($b);
print_r($b);
echo "\nasort(array(0,1,-1,0,-2,2,NULL))\n";
asort($c);
print_r($c);
?>
$ php a.php
asort(array(1,-1,0,NULL,2,0,-2))
Array
(
[5] => 0
[2] => 0
[3] =>
[6] => -2
[1] => -1
[0] => 1
[4] => 2
)asort(array(NULL,-1,0,1,2,-2, 0))
Array
(
[5] => -2
[1] => -1
[6] => 0
[2] => 0
[0] =>
[3] => 1
[4] => 2
)asort(array(0,1,-1,0,-2,2,NULL))
Array
(
[6] =>
[4] => -2
[2] => -1
[3] => 0
[0] => 0
[1] => 1
[5] => 2
)
Для таких случаев передается второй аргумент (SORT_NUMERIC, SORT_STRING, etc). По-умолчанию используется SORT_REGULAR (без преобразования типов) и результат сортировки значений разных типов может быть непредсказуемым (о чем так же ясно сказано в документации).
+ usort в сочетании с лямбдами позволяет определить какое угодно условие сравнение.
Короче, rtfm.
Ты крайне наивен, если думаешь, что SORT_NUMERIC делает порядок детерминированным.asort(array(1,-1,0,NULL,2,0,-2))
Array
(
[6] => -2
[1] => -1
[5] => 0
[3] =>
[2] => 0
[0] => 1
[4] => 2
)asort(array(NULL,-1,0,1,2,-2, 0))
Array
(
[5] => -2
[1] => -1
[6] => 0
[2] => 0
[0] =>
[3] => 1
[4] => 2
)asort(array(0,1,-1,0,-2,2,NULL))
Array
(
[4] => -2
[2] => -1
[6] =>
[3] => 0
[0] => 0
[1] => 1
[5] => 2
)К тому же, если делать RTFM, полезнее тратить время и силы на изучение вменяемых языков, а не этого грабельного поля.
> Ты крайне наивен, если думаешь, что SORT_NUMERIC делает порядок детерминированным.Нет. Просто если SORT_NUMERIC подразумевает приведение значения к числу при сравнении, т.е. null приводится 0. Поэтому результат и зависит от исходной позиции в массиве.
Чтобы перечисленные примеры вернули идентичный результат, нужно использовать SORT_STRING.
> использовать SORT_STRINGдля сортировки массива чисел? Не, я не готов принимать столько упорина.
Для сравнения аналогичная сортировка в питоне:
In [2]: a = [0,1,2,None,-1,-2,0]
In [3]: a.sort()
In [4]: a
Out[4]: [None, -2, -1, 0, 0, 1, 2]In [5]: a = [None,0,1,2,-1,-2,0]
In [6]: a.sort()
In [7]: a
Out[7]: [None, -2, -1, 0, 0, 1, 2]In [8]: a = [0,1,2,-1,-2,0,None]
In [9]: a.sort()
In [10]: a
Out[10]: [None, -2, -1, 0, 0, 1, 2]
> для сортировки массива чисел? Не, я не готов принимать столько упорина.Для сортировки массива с _разными типами данных_.
> Для сравнения аналогичная сортировка в питоне:
Вы действительно не видите разницы? Python не преобразуем None к числу, как делает PHP. Вместо этого "Objects of different types except numbers are ordered by their type names". Поэтому результаты и оказываются одинаковыми. Но с чего вы взяли, что такое поведение является единственно верным? Потому что так сделано в Python? Вы уверены что это удобно в контексте любой реальной задачи? В Python3, например, вообще будет TypeError. Если нужно такие же правила в PHP - usort в помощь, определите свою функцию сравнения с какими угодно правилами.
> Вы действительно не видите разницы?Разница очевидна.
> Но с чего вы взяли, что такое поведение является единственно верным?
С тоо, что результат сортировки массива должен быть детерминированным независимо от порядка значений, т. к. иное не приносит пользы, но приводит к неочевидным, трудновоспроизводимым багам.
> определите свою функцию сравнения с какими угодно правилами.
то есть, вы признаете, что для того, чтобы можно было писать на PHP, нужно в куче мест переопределять его дефолтное поведение.
> Разница очевидна.Тогда зачем вы приводите этот алгоритм в качестве аналога?
> С тоо, что результат сортировки массива должен быть детерминированным независимо от порядка значений,
Ещё раз: если мы явно принимаем null за число (приводя его к 0), то результат получается вполне детерминированным.
> т. к. иное не приносит пользы, но приводит к неочевидным, трудновоспроизводимым багам.
А помещать None значения тупо перед всеми числовыми - это по-вашему «приносит пользу»? Сортировать значения на основе имен их типов - это "полезное" и очевидное поведение? О какой пользе вообще речь? Вам не приходит в голову, что это сильно зависит от контекста?
> то есть, вы признаете, что для того, чтобы можно было писать на PHP, нужно в куче мест переопределять его дефолтное поведение.
Какой-то у вас странный вывод из моих слов. Давайте вернемся. Я сказал, что если нужно изменить поведение в данном конкретном случае — вы можете это сделать. А вы заключили, что необходимо менять дефолтное поведение «в куче мест». Проблемы с логикой?
И при чем здесь вообще PHP? Если вас не устраивает поведение по-умолчанию, то вы изменяете его, вне зависимости от того, на каком языке пишете.
А можно только один вопрос: это когда это NULL у нас стал числовым типом?
> добавлены константные скалярные выражения, функции с переменным числом аргументов, ... оператор возведения в степеньFacepalm. Если этого не было и добавлено только сейчас. Жесть.
>константные скалярные выраженияБыло, define(ONE, 1);
Но тут скорее аналог не сишных констант, а сишных макросов.
>оператор возведения в степеньБыло, функция pow. Теперь сделали и оператор.
>функции с переменным числом аргументовНе знаю, не пользовался. Не могу придумать кейс, при котором это было бы полезно. Опциональных аргументов и массивов в качестве параметров более чем достаточно.
>функции с переменным числом аргументовБыло, но не так удобно - приходилось аргументы выцарапывать через func_get_args / func_num_args + func_get_arg, плюс эти функции возвращали _все_ переданные аргументы. Самая мякотка ...$args в том, что $args не включает эксплицитных аргументов.
> Не знаю, не пользовался. Не могу придумать кейс, при котором это было
> бы полезно.Людям, которые не ели ничего слаще морковки, очень сложно сходу придумать применение сахару. Например, им не приходит в голову, что сахар можно класть в чай, ведь с морковкой подобное было бы глупо.
Ничего лет через пять будете удивляться, как вы без этого обходились. И еще на шаг приблизитесь к пониманию причин, по которым вас жалеют.
Обходились, и обойдемся впреть.С трудом представляю ситуацию когда функции "действительно необходимо" самостоятельно разбирать свои аргументы, если вас обламывает запихнуть опциональные аргументы в массив, это ваши трудности, зато код значительно более читаем, так что сомнительная "инновация", добавленная в угоду питоноупоротых.
> Вместо приведения кейса, я перейду на личности и ещё раз пёрну в лужуОк, твои доводы мне ясны
> Добавлен новый математический оператор "**", применяемый для возведения в степеньНе прошло и 19 лет... Или прошло?
Серьёзно? Вам настолько не хватало этого?> Не прошло и 19 лет... Или прошло?
В Си уже 40 лет без него как-то обходятся. В Java — лет двадцать. И в половине других языков. Может вы всё-таки преувеличиваете ценность этой фичи?
Всем, кому вкладывали на основах программирование конструкцию "a^b" очень-очень не хватало этого математического оператора. Хотя мне сильнее не хватало sqr/sqrt, хоть я уже 20 лет не считаю себя программистом, но в 75% так называемых калькуляторов до сих пор нет кнопки извлечения корня, не говоря уже о возведении в степень - думаю, как раз из-за отсутствия простых реализаций в тех языках, на которых эти калькуляторы написаны.
О каких "калькуляторах" речь? Я, наверное, не до конца вас понимаю, но написание калькуляторов — это не самый стандартный кейс для PHP. Или нет?
> написание калькуляторов — это не самый стандартный кейс для PHPвот щаз я так и представил -- реализацию калькулятора как web-страничка (без Javascript)...
...и каждая кнопка (и цифры и операции) это анкорная ссылка вида ---
< a href="?...">...</a>:-)
да, PHP-программисты такое могут, и они наверняка даже не заподозрять ни чего неладного в этом :)
>они наверняка даже не заподозрять ни чего неладного в этом :)Угу, точно так же, как ты до сих пор не заподозрил ничего неладного в орфографии.
>>они наверняка даже не заподозрять ни чего неладного в этом :)
> Угу, точно так же, как ты до сих пор не заподозрил ничего
> неладного в орфографии.именно так. да. хорошее сравнение! :-)
А в других _скриптовых_ языках этот оператор есть. И в пых его в конечном итоге добавили. Значит таки он был нужен в языке с самого начала. Как и множество других фич. Это очень смешно наблюдать как пых реализует постепенно вещи, которые давно есть в языках, существовавших до его рождения. Сначала быдлокодерам выкатили примитивный язык, а теперь потихоньку(чтобы не перегрелись мозги ЦА) доводят язык до нормального.
а когда разработчики-PHP собираются доводить PHP -- до ситуации когда каждый HTTP-запрос не будет поновой (поновой каждый раз) вычислять декларацию классов?допустим я в PHP-файлах задекларировал 200 классов, и в каждом HTTP-запросе использую несколько классов (не все сразу, но разные в зависимости от ситуации).
то есть -- мне нужно чтобы некоторая часть PHP-кода -- вычислялась бы ТОЛЬКО один раз (при старте HTTP-сервера) , а во время дальнейших HTTP-запросов уже использовалось бы то состояние которое УЖЕ было вичислено тот 1 раз (а не вычислялось бы каждый раз поновой).
http://daemon.io/
> http://daemon.io/интерфейс совместимый с апачевским mod_fcgid -- тут есть? или это просто поделка, которая сама-в-себе и слабо связанна с Apache HTTP Server ?
(поумолчанию в качестве нормальной работы -- апачевский mod_fcgid передаёт fastcgi-демону сокетный объект как файловый дескриптор с номером 1 .. БЕЗ всяких-там "/tmp/phpdaemon.fcgi.sock". это считается штатной и качественной ситуацией, так mod_fcgid может (и должен!) запускать одновременно несколько экземпляров fastcgi-демонов, и эти fastcgi-демоны не должны друг другу мешаться)
где документация вообще?
и насколько вся эта система в итоге будет совместима со всякими legacy-конструкциями типа $_SESSION[...] и $_REQUEST[...] ? (для целей legacy-кода, например "вставить SAPE-ссылки")
если с legacy получается облом -- то зачем тогда вообще терпеть этот PHP ? PHP бесполезен без Legacy, так как проще взять https://pypi.python.org/pypi/flipflop и https://pypi.python.org/pypi/bottle :-)
>>> так как проще взять https://pypi.python.org/pypi/flipflop и https://pypi.python.org/pypi/bottleЧестно - мне уже от одних ссылок плохо. Pypipypypipypypypypypipipy.
В описании оператора ** трогательно обойдён вопрос ассоциативности.
Как вы думаете, 2**1**2 вернёт 2 или 4?
> Как вы думаете, 2**1**2 вернёт 2 или 4?<troll>Думаю, вернёт 3 -- это же PHP.</troll>
я достаю из широких штанин, дебианом бесценного груза:> apt-get install php5-cli
> php --versionPHP 5.6.0RC4 (cli) (built: Aug 19 2014 15:27:20)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0-dev, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologiesphp -r 'echo 2**1**2;'
2
мы не думаем, мы знаем...
> php -r 'echo 2**1**2;'
> 2Это полный !@#$%^.
Степени возводятся справа налево.
> Степени возводятся справа налево.При обычной алгебраической записи (двойка, у неё в уголке единица и у единицы в уголке двойка) так бы и было.
Ниже в комментах написали, что доки PHP на эту тему противоречат друг другу. В одном месте написано слева направо, в другом -- наоборот.
:)
> В описании оператора ** трогательно обойдён вопрос ассоциативности.
> Как вы думаете, 2**1**2 вернёт 2 или 4?LOLWUT?
http://ru2.php.net/manual/en/language.operators.precedence.php
>> В описании оператора ** трогательно обойдён вопрос ассоциативности.
>> Как вы думаете, 2**1**2 вернёт 2 или 4?
> LOLWUT?
> http://ru2.php.net/manual/en/language.operators.precedence.phpКак бы не так. В документации написано, что операция "**" -- лево-ассоциативна. То есть возведение в степень должно идти слева направо (2**1)**2. А Буратино показал, что реализация противоречит документации. Вот тебе и LOLWUT...
Спасибо за ссылку, есть ещё http://ru2.php.net/migration56.new-features#migration56.new-... , где написано «A right associative ** operator has been added to support exponentiation, along with a **= shorthand assignment operator.» и пример вычисления 2 ** 3 ** 2 с результатом 512.т.е. материалы на сайте противоречивы.
> т.е. материалы на сайте противоречивы.Вы ещё хотите, чтобы т.н. "разработчики" т.н. "языка программирования" PHP различали где "право", а где "лево"? Может они ещё и таблицу умножения должны знать?
Вы слишком многого хотите:)