Как стать автором
Обновить

Комментарии 39

Чувствую php7 будет обновлен по полной, начиная с производительности, заканчивая кучей фич, которых так не хватало.
Хотя вроде Дмитрий Стогов говорил, что JIT появится только после релиза версии с вмерженной phpng.
PS
↑↑↓↓←→←→ba↵

Напоминает выполнение fatality в MK.
Чувствую php7 будет обновлен по полной, начиная с производительности, заканчивая кучей фич, которых так не хватало.

Я вот каждую неделю заглядываю на rfc. И если раньше успевал выучить новые фичи до выхода самого языка (5.5, 5.6), то сейчас даже понять всю глобальность изменений не успеваю. Такое ощущение, что 7ой пых будет вообще совершенно новым языком, столько они туда всунули, движуха там безумная творится. Действительно, только попкорном и можно запасаться.
Ну JIT-а не будет на уровне языка пока что. То, что они открыли, это не JIT, это сложно как-то назвать вообще. Нормальный жит возможно будет позже, либо в 7.1, либо в виде экстеншена.
> Библиотеки доступны для всех популярных языков, включая PHP.
> Libraries for Objective-C, PHP and C# are in development

На гитхабе их вроде тоже нету.
Доступны надо заменить на анонсированы, тогда будет правдой!
jbroadway/urlify — Библиотека для генерации урлов (slug), поддерживает транслитерацию. Порт URLify.js из Django.

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

Для транслита следует использовать php.net/manual/en/class.transliterator.php
По мне использование своих либ помимо встроенных гостовских происходит потому, что не всем нравится эти правила транслита. К примеру, там «х» это «kh» и прочее.
ну а какой вариант может быть кроме kh?
intl предоставляет разные инструменты. не обязательно свой велосипед лепить, изначально криво работающий.
«khockey»?
а как? hudozhnik?
ну почему просто не использовать h?
Мы же так и читаем «кх» зачем там лишний звук. Или «x» вместо «ks»
потому что есть правила транслитерации. то, что вы используете какие-то свои правила, не отменяет правил общих.
Также станет возможным отлавливать ошибки парсинга.
А для чего это может понадобится?
Например, выводить ошибки красиво вот так:

image
Это и сейчас можно, просто не очень тривиально и недостаточно надёжно.
Небольшой оффтоп:
Не могу не упомянуть про github.com/filp/whoops (1966 звёздочек, что говорит о крутости пакета).

Ну просто потому, что умеет открывать место ошибке в редакторах, конвертировать данные в формат для newrelic (и прочих, вместе с монологом) или показывать полный трейс с состоянием на каждый момент выполнения программы. Да и ставится одной строкой, что исключает «не очень тривиально».
Это всё понятно. Под «не очень тривиально» я имел ввиду не использование готового, а написание своего. Если whoops поднимет требования до PHP7, а рано или поздно это случится, его код прилично похудеет.
Ну это само собой. Кстати, а почему Yii2 не использует whoops? Он же вроде как и качественнее и больше информации предоставляет, и разгрузка для комьюнити (перекладывание ответственности).

UPD. Имею ввиду, что может в нём какие-то подводные камни есть, о которых следует знать и из-за которых вы от него отказались?
Мы Yii 2.0 начали когда его ещё не было, в середине 2011. Whoops только только начали разрабатывать в середине 2013-го, к этому моменту уже была выпущена публичная версия Yii 2.0, выкидывать уже отлично работающий код и заменять его тогда ещё сырым whoops было явно плохим решением.
Самое важное, что это позволит разрабатывать долгоживущие процессы, которые не будут падать из за подобных ошибок.
Ещё бы как-нибудь exit и die можно было бы выключить, было бы вообще прекрасно.
PHP активно готовится не умирать.
Как всегда — огромное спасибо за новости!
Да да, слежу за ними, но анонс совсем скромный, поэтому решил дождаться уже финального релиза.
RFC: Consistent Function Names — наконец-то!
Добавьте апдейт, что STH Dual Mode был принят, драма из овер.
Жаль, лично мне он не особо нравился. По-моему вариант с:
function foo( int $a, float $b ) {} // строгий каст

function foo( (int)$a, (float)$b ) {} // с привидением типов

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

Я лично вижу лучший вариант только просто строгие типы, но это за гранью возможного.
Строгие типы доступны в виде SPL расширения, а также можно использовать аннотации (например вместе с doctrine annotaions пакетом). А вообще да, наверное лучше определять логику пользователем.
По поводу «эпопеи тайп-хинтинга» — простите за крамолу, но, кажется, не так он и нужен.
То есть я воинствующий адепт типизации и всё такое.
Но всё равно как бы не сделали, это будут полумеры, криво и в рантайме, то есть тормозов больше чем пользы.

С другой стороны IDE поддерживают phpdoc с указаниями и скаляров и типизированных массивов и перечисления типов.
Мне phpStorm на такие ошибки указывает, которые встроенный тайпхинтинг никогда не нашёл бы. И всё это статично.
Имхо, в подобном направлении статичного анализа и стоило бы развиваться.
НЛО прилетело и опубликовало эту надпись здесь
Я бы сказал не «во многих», а во всех. Boris проигрывает в хламидомонаду псишу по всем мыслимым пунктам =)
НЛО прилетело и опубликовало эту надпись здесь
С последним пунктом не могу не согласиться, но что значат первые два? На практике.
НЛО прилетело и опубликовало эту надпись здесь
Проверил только что — PHP 5.6 и 5.5, действительно есть такая проблема (с циклами), в отличие от boris, раньше не замечал, благодарю.

После ^C Boris закрывается перманентно (сразу же, без вопросов), psysh при этом спрашивает «Terminate batch job (Y/N)?» (т.е. ситуация ровно противоположная). Опять же — только что проверил.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий