PHP 5.4 alpha1

[@ostapbender]

Добавлено Array dereferencing

Не прошло и семи лет.

[@WebSpider]

Я смотрю тут бóльшая часть комментариев про этот array dereferencing. Чего уж скрывать — меня эта новость тоже порадовала :)

[@moooV]

Как же я этого ждал. Пойду открою шампанское с красной икрой!

[@WebSpider]

Эх, когда же они введут короткие записи для массивов… Люди тоже уже давно просят, а они всё никак

[@impwx]

Может вам посмотреть в сторону других языков, в которых это есть? Зачем ограничивать себя PHP?

[@WebSpider]

А кто вам сказал, что я не программирую на других языках? :) Просто по роду деятельности приходится и на пыхе писать тоже. И от этого ещё больше не хватает этой фичи

[@impwx]

Да, если работа обязывает — никуда не денешься. Но, увы, мне почему-то кажется, что за то время, пока PHP Core Team добавит короткий синтаксис для массивов, вы успеете сменить не один проект и не одну компанию :)

[@VolCh]

Я, например, на руби пишу для себя (наверное не следуя ruby way и rails way), зарабатываю на жизнь пыхом, коммерческий проект собираюсь запустить тоже на пыхе.

[@DenisO]

Я читал про PHPON — короткую запись массива, аналог JSON'а в PHP. Это было в каком-то списке фич для голосования что внедрять. Официальном по моему.

[@WebSpider]

Один раз уже разработчики отклонили этот feature request, хотя большинство пользователей проголосовали за. Сейчас (к выходу версии 5.4) опять устроили голосование по этому вопросу

[@LastDragon]

Где проголосовать? :)

[@reket]

Голосуют разработчики. Вот результаты wiki.php.net/rfc/shortsyntaxforarrays/vote

[@impwx]

Страшно представить, какая каша у них там в коде, если фича такого рода заставляет главного разработчика сказать «I can't tell you if it'll ever be supported.»

[@MTonly]

Шутка ли — писать объектно-ориентированный PHP на процедурном C. ;-)

[@impwx]

Скорее «поддерживающий некоторые объектно-ориентированные возможности». ;-)

Честно говоря, не могу вообще понять, почему с этой фишкой такие сложности. Исходя из моего опыта написания парсеров \ трансляторов, всё дело только в приоритете операций и правильном написании БНФ, по которому потом автоматически сгенерируется скелет парсера.

Да, кстати, если кто-нибудь установил, проверьте пожалуйста, а такая конструкция сработает?

$a = new A;
$b = new B;
$flag = mt_rand(1, 1000) > 500;

($flag ? $a : $b)->hello();

[@WebSpider]

Нет, не сработает

[@impwx]

Так и знал. Правят частные случаи, а не систематизируют грамматику.

[@bolk]

А почему вы говорите, что этот язык только поддерживает некоторые ОО-возможности?

[@impwx]

Если считать, что объектно-ориентированным считается любой язык, поддерживающий инкапсуляцию, наследование, полиморфизм и абстракцию — тогда вы безусловно правы, PHP поддерживает всё вышеперечисленное.

Я же имел в виду, что php является не чисто объектным, поскольку ООП не было заложено в него изначально, а появилось постепенно и хаотически. Примером этого могут служить следующие факты:

• Наличие «базовых» типов данных, не являющихся объектами и не участвующими в иерархии
• Наличие глобальных функций, не привязанных к классам, с помощью которых ведется работа с объектами базовых типов
• Невозможность перегрузки операторов (за исключением оператора [ ])

[@chEbba]

По двум фактам из трех и Java не проходит. Но доля правды есть конечно.

[@bolk]

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

Наример, из Википедии можно узнать, что «JavaScript, also known as ECMAScript, is a prototype-based, object-oriented scripting language».

Но в JS есть базовые типы, не являющиеся объектами и нет возможности перегрузки операторов, за редким исключением.

[@impwx]

Да, согласен с вами. Едва ли существует язык, который содержит в себе вообще все возможности, относящиеся к ООП. В некоторых их больше, в некоторых меньше. Но я все же остаюсь при мнении, что PHP скорее поддерживает ООП как дополнительную парадигму, нежели является истинно объектно-ориентированным языком.

[@Tigg3r]

Когда там уже с PHP6 выйдет с обещанной многопоточностью?

[@dmitriid]

Что там в этой 6-й версии вообще будет, непонятно. У них в минорных версиях периодически столько изменений, что тянет на отдельную версию.

[@reket]

Многопоточность? Можете её не ждать. Недавно обсуждалось разработчиками, что архитектура пыха не позволяет полноценно реализовать.

[@Tigg3r]

Пропустил эти обсуждения…
Почему-то я не удивлен.

[@ignar]

А еще помню PHP 3… Ну чего там, я рад за PHP'шников и за язык.

[@Vladson]

помню PHP 3

Да уж… Забудешь такое… Как же…

[@homm]

Что-то я не понял:

function &foo(&$foo) {
	return $foo;
}
 
$a = array(1);
$b = foo($a)[0];
$b = 2;
var_dump($b); // array(1) {  [0]=>  int(2) }

Мне кажется, в последней строчке ошибка и выводится $a, а не $b. Или я не все понял?

[@SowingSadness]

$b ссылается на 0-вой элемент массива $a
Так что, все верно.

[@homm]

> $b ссылается на 0-вой элемент массива $a.
Да. И мы ему, первому элементу присваиваем значение 2. Потом его, первый элемент, выводим и получаем массив. Откуда?

[@WebSpider]

Пожалуйста, сообщите о результатах в список рассылки QA ([e-mail]) и/или в баг-трекер PHP

[@caveman]

Наверно, все-таки опечатались в доке:
vardump($a);

[@Vir]

> Array dereferencing

Наконец таки!!!

[@Nc_Soft]

Ах вот как оно называется. Да, бесило переменную заводить лишнюю.

[@torbasow]

Оно называется «разыменование массивов».

Помню, я чувствовал себя почти оскорблённым, когда много лет назад, осваивая PHP после Javascript, как само собой разумеющееся применил такую запись — и обнаружил, что она принципиально не работает!

[@WebSpider]

А как же scalar type hints?

[@reket]

Выпилили :(

[@WebSpider]

Ну и ладно. Всё равно в том виде, в каком они хотели сделать, от них было бы больше вреда, чем пользы, имхо. Пусть хорошенько подумают и может в следующей версии сделают нормально

[@reket]

Это и стало причиной отказа, сыровато еще для внедрения.

[@SonicGD]

Добавлено Array dereferencing

Неужели

[@Hast]

> синтаксис break/continue $var
Не совсем понял, видимо никогда не использовал. В чем заключается изменение?

[@WebSpider]

Как я понял что-то вроде этого:

$s = 2;
...
break $s;

Надеюсь просто break 2 и continue 2 оставили. Фича редкоиспользуемая, но пару раз очень нужной оказалась

[@feedbee]

Все верно. Я по началу тоже испугался :) break и continue незаменимые ключевые слова, которые часто юзаются на практике в циклах, убрать их полностью — бред. Ну про case и break вообще молчу.

[@WebSpider]

Речь идёт ни в коем случае не о полном убирании break и continue, и даже не об убирании таких конструкций как continue N и break N (где N — число). Теперь всего-навсего нельзя будет использовать переменные в этих конструкциях

[@torbasow]

Плохая фича; провоцирует написание не очевидного кода. Выносим, скажем, блок кода, выглядящий как изолированный, в функцию и — вуаля! — программа перестаёт работать, потому что он на самом деле не изолированный, из него тянется это неуместное напоминание о спагетти-эпохе GOTO.

[@shmaltorhbooks]

если не ошибаюсь Array dereferencing по-русски называется «контекст массива»? или не то пальто?

[@Hast]

function fnc() {
return array(1, 2, 3);
}

echo fnc()[0]; // return 1

Как-то так. А как оно переводится — без понятия.

[@WebSpider]

я бы сказал «разыменовывание»

[@impwx]

По смыслу тут скорее «индексация произвольного выражения».

[@casey]

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

[@torbasow]

И напрасно не хотелось. С этим нужно было бороться во имя ООП.

[@Hast]

А почему автор не записал в список основных изменений повсеместный уникод? Как по мне, так довольно ожидаемая и важная штука.

[@WebSpider]

Можно ссылочку? О чём там конкретно?

[@grevus]

www.php.net/releases/NEWS_5_4_0_alpha1.txt

[@WebSpider]

Нашёл там только

Changed default value of «default_charset» php.ini option from ISO-8859-1 to UTF-8. (Rasmus)

Вы это имели ввиду под «повсеместным уникодом» или я что-то не увидел?

[@grevus]

Ещё:
Added multibyte support by default. Previously php had to be compiled with --enable-zend-multibyte. Now it can be enabled or disabled through zend.multibyte directive in php.ini

[@MTonly]

Насколько я понимаю, расширение mbstring просто включили по умолчанию + значение конфиг-параметра default_charset по умолчанию изменили с ISO-8859-1 на UTF-8. Это отнюдь не та полная поддержка Юникода, которая ожидалась (ожидается?) от PHP6.

[@WebSpider]

Согласен. На полноценны юникод совсем не тянет. Это даже не новая возможность, а просто изменение конфигурации по умолчанию

[@VolCh]

Но уже жить станет проще.

[@WebSpider]

Что-то пока не очень много нововведений по сравнению с 5.3 (не считая traits и пресловутого array dereferencing). У 5.3 по сравнению с 5.2 куда больше было фич (неймспейсы, анонимные функции и т.д.). Будем надеяться ещё добавят разных вкусностей. Лишь бы не испортили хорошие идеи, как это, к сожалению, иногда бывает

[@reket]

Это не окончательный список. В следующих альфах добавят новенького.

[@shmaltorhbooks]

а будет ли такая фича?

$y = ($x = func())[0]

или я слишком многого хочу?

[@WebSpider]

А вы скачайте и попробуйте :)

[@alagar]

разрешите поворчать
для неймспейсов выбрали cимвол "\" потому что все остальные символы уже заняты и как бы не хотелось нагружать компилятор
«use» выбрали для Traits хотя тот же «use» используется для тех же неймспейсов

[@WebSpider]

Полагаю тут причина в том, что в контексте использования они не пересекаются (т.е. точно можно определить что имеется ввиду). С разделителем неймспейсов немного другая ситуация. Например, если бы выбрали символ "::", то возникли бы неоднозначности.

echo SomeObj::somefunc();

что тут имеется ввиду — функция неймспейса или статическая функция класса? Конечно можно было бы определить приоритеты, но интерпретатору приходилось бы тратить время на анализ и проверку всех возможных ситуаций

[@alagar]

да не хотели разработчики лишней возни с оптимизацией и прочем

[@bolk]

Оптимизация тут причём? Как бы вы приведённый код читали?

[@alagar]

ой ну там вариантов было море echo SomeObj::somefunc(); - метод класса
echo (SomeObj)::somefunc(); неймспейс
можно было Fatal error кидать если возникала неопределенность и добавить возможность переименования namespace аки в C++ (вроде есть там что то подобное)
а в обще рассматривали разные варианты wiki.php.net/rfc/namespaceseparator-

[@bolk]

Не вижу чем приведённые вами варианты лучше обратного слеша.

[@alagar]

это дело вкуса, давайте оставим эту дискуссию троллить на эту тему можно долго, но уже бесполезно. ИМХО обратный слеш уродство

[@Aco]

я бы предложил:

[@Aco]

то есть ":" и предложил

[@alagar]

php.net/~helly/backslash-colored.html живой пример кода с неймспейсами как то ужасненько местами

[@gro]

Тоже поначалу нервировало, а потом привык и не замечаю.

Гораздо сильнее нервирует то, что для namespace нет автолоада, как для классов, так что простые наборы функций приходится по прежнему оборачивать в классы.

[@safron]

Плохо выглядит, когда повсеместно применяется к стандартным функциям (что, кстати, не обязательно):

if (\count($err)) {};

А в остальном вроде ничего:

self::prepare(new Package\Dependency($dep, $package, false, true));

Зато можно визуально легко различать, двойное двоеточие было бы хуже.

[@SharkyFLY]

массивчики няшные)

[@DjOnline]

APC уже наконец стал совместим с factcgi, перестал создавать кэши для каждого посетителя персонально?

[@unno]

• Simplified string offset reading. $str[1][0] is now a legal construct.
• Added support for storing upload progress feedback in session data.
• <?= is now always available regardless of the short_tags setting

[@Morfi]

Радует что сделали $this для замыканий

[@WebSpider]

Прошу прощения, может я что-то не понимаю, но

$s = function() {
  var_dump($this);
};

$s(); // Выводит NULL

Что я делаю не так?

[@Irker]

$this должен указывать на объект, в котором определено замыкание. В вашем случае замыкание определено вне объекта.

[@WebSpider]

Понятно, спасибо

[@everzet]

Вернули $this в кложуры же!

[@yuretsz]

Мультинаследование четкое запилили, очень много интересных идей навеяло.

[@Psih]

В эту альфу не всё вошло, следующая будет скорее всего через 2-3 недели (чуть раньше) и в ней будет встроенный CLI веб сервер и пачка других плюшек.

[@gro]

allow_call_time_pass_reference печально, что убрали.
Мне самому это не нужно, но иногда приходится что-то исправить в старье каком-то, а том передача с "&" зачастую бывает используется.

[@reket]

От тяжелого воза наследия надо когда-то избавляться.

[@niisan]

Странно, что топикстартер не упомянул об очень важной особенности:

Removed legacy features:
10. Safe mode and all related ini options.

[@Hast]

Кстати про goto что-то известно? Разработчики обещали его (если быть точнее — его аналог) в ближайших версиях.

[@reket]

В 5.3 давно есть.

[@torbasow]

Только — зачем?

[@sylvio]

Расмус — мудак совершенно особого качества, если бы майнтейнером был кто угодно другой, мы бы имели все плюшки дереференсинга еще лет 5 назад, без отмазок «это не php-way».

[@WebSpider]

просто их говноскрипты не будут работать под новыми версиями :)

[@resurection]

Не завидую я битриксойдам. Им же пол миллиона файлов придётся перелопатить…

[@bolk]

Зачем лопатить? Указываешь в ini prepend_file и в нём шлёпаешь переменные из суперглобалов в глобальный скоуп.

[@resurection]

Вообще конечно да. Они это могут. Даже в ini ничего прописывать не обязательно. Можно в самом начале index.php (или в битриксе header.php) написать extract() и всё.

С такими разворотами, получается, зря убрали из настроек — говнокода только прибавится.

[@adamant]

А что, Битриксу разве требуется register_globals? Покажите, откуда Вы это взяли?

[@AlexeyDsov]

Вот почему в traits нельзя кроме функций еще и переменные объявлять?? Часть вкусностей, которые сходу в голову приходят, отбрасываются из-за этого :(
Или это не верно совсем?

[@AlexeyDsov]

Там в примерах не видать. А затестить сейчас не могу. Таки обломали или нет? :)

[@WebSpider]

Вот почему в traits нельзя кроме функций еще и переменные объявлять??

Ну почему же нельзя? Вполне себе можно:

trait Tr {
  public $s = 'cool';
}

class SomeClass {
  use Tr;
}

$s = new SomeClass;
echo $s->s; // cool

[@VolCh]

Ещё лет дцать и можно не стыдиться, что основной язык PHP :)

[@safron]

можете уже сейчас не стыдиться

[@vadimbelyaev]

На любом языке можно писать как хорошо, так и плохо.

[@egorinsk]

Ну что я скажу. Array dereferencing — в общем-то не нужен, так как поощряет неэффективный код (вернуть массив, ради одного элемента). А вот traits — гораздо более интересная вещь, так как теперь модельки со всякими расширениями типа Countable, Cacheable, и т.д. станет писать проще. Но traits все же имеют недоработку — нельзя импортировать в класс 2 трейта с одинаковыми именами функций, чтобы при этом вызывались обе.

Теперь хотелось бы работы по повышению производиетльности, так как я замечаю, что подключение и интерпретация файлов (даже с байт-код кешером) занимает больше времени, чем полезная работа. Например, на моем (быстром) ноутбуке SQL-запрос занимает максимум 300-400 мкс. Обращение к кешу — того быстрее. То есть, получение всех нужных данных занимает максимум 3-5 мс в сумме для сложных страниц. А вот загрузка PHP-классов, инициализация и прочая бесполезная хрень занимают куда как больше, из-за чего скрипты тормозят :(

Особенно тормозят циклы и подключения классов, где есть хотя бы несколько десятков функций (в том числе если они унаследованы) — это работает нереально медленно. То есть класс даже с 1 функцией, наследующийся от большого класса, создается очень медленно (до 1 мс). Если бы команда PHP перешла уже от свой дурацкой модели «перезапуск скрипта при каждом запросе» к «приложение запускается один раз и обрабатывает много запросов».

Ну а если использовать чужие фреймворки-монстры, типа всяких зендов/Yii/симфоний, где объектов и классов еще больше, то все работает еще хуже и медленнее, вот (( Прям не знаешь что делать, то ли на Java/D/C++ начинать пытаться писать (что тоже несет массу проблем), то ли терпеть эти все тормоза. Все же скриптовое прошлое PHP дает о себе знать.

[@VolCh]

True FastCGI вроде как реализовать можно и даже уже реализовано, но вот насколько стабильно оно работает затрудняюсь сказать, считается что движок языка течёт, но пруфов как-то не встречал… Плюс к потенциальным утечкам памяти самого движка добавляются утечки приложения. Конечно, в других языках как-то справляются, но привычка вторая натура :)

[@egorinsk]

Лично ни разу не сталкивался с настоящими утечками памяти, даже на PHP 5.2, где не было сборки мусора (например, при работы долговыполняющихся консольных скриптов). Единственный пример — библиотека phpQuery (вроде она) потребляет память, не освобождая её, но тут скорее виновата сама библиотека.

Тем более, для веба какие-то сложные иерархии объектов с кольцевыми ссылками не нужны, модельки, котроллеры и шаблоны, что там еще нужно, так что там эта проблема просто не актуальна.

Да и можно через каждые 10 000 запросов, например, перезапускать воркера.

Но хотелось бы, чтобы true FastCGI был встроен, блин, в PHP! Включая, например парсинг POST-запросов. А не собран из библиотеки libev и кучи костылей, как в phpDaemon, с перехватами функций, и прочими извращениями. Достаточно заглянуть в его исходники, чтобы расхотеть им пользваться.

[@VolCh]

Лично сталкивался при попытках писать демонов ещё в PHP3. Хотя, конечно, наверняка мои кривые руки виноваты, чего-то где-то не освобождал, не удалял, не закрывал…

Кольцевые ссылки для веба очень, по-моему, актуальны — простейшая двусторонняя связь один-к-одному (пользователь <-> профиль, например) и вот уже у нас кольцо.

Конечно же хотелось бы. Но, думаю, у разработчиков есть причины не реализовывать это и не только лень.

[@egorinsk]

> Кольцевые ссылки для веба очень, по-моему, актуальны — простейшая двусторонняя связь один-к-одному (пользователь профиль, например) и вот уже у нас кольцо.

[@egorinsk]

> Кольцевые ссылки для веба очень, по-моему, актуальны — простейшая двусторонняя связь один-к-одному (пользователь профиль, например) и вот уже у нас кольцо.

Так можно хранить не ссылку на объект (что довольно глупо по моему), а ид связанного объекта, а сами объекты хранить в массиве в памяти — нет ссылок, нет проблем. Это же не C++, тут можно и без указателей жить.

[@VolCh]

Массивы делать глобальными? Иначе как получить доступ к профилю из произвольного места? Ведь вместо $user->profile надо писать $profiles[$user->profile_id]. Да и с lazy load проблемы могут быть…

[@egorinsk]

1) В объект user добавляется метод getProfile(), который прячет в себе алгоритм получения данных профиля.

2) Создается единственно экземплярный класс с названием типа ProfilesRepositiory, в нем и прячется этот массив. Класс по просьбе (ProfilesRepositiry::getProfileById($id)) достает любой профиль либо из массива, либо из БД, либо из кеша, либо еще откуда нибудь — мы в любой момент можем менять алгоритм получения этих данных, не трогая остальной код.

3) lazy load и все прочее работает без проблем, так как алгоритм получения данных спрятан в единственном классе, и его можно менять не ломая код.

А глобальные переменные — это гадость и вредно для понимания и поддержки кода.