В статье будут рассмотрены темы: — Развитие синтаксиса PHP — Будет дан ответ на аксиому "почему только 5.3, не выше?" и что из нового синтаксиса можно. — Вопрос совместимости, "исторические хвосты"
Мы в данный момент работаем по версии 5.3. Ниже я описываю новые улучшения в 5.4 и 5.5. К сожалению, возможности из этих версий пока использовать НЕЛЬЗЯ. Можно использовать только возможности 5.3.
Важно! Пиши на PHP 5.3! Все вещи, которые доступны выше 5.3 необходимо решать путем создания промежуточных вспомогательных переменных!
Итак, чтобы рассмотреть эту аксиому подробнее, рассмотрим эволюцию синтаксиса PHP, что же появилось в новых версиях (будут рассмотрены не все улучшения, а только вопросы коротких разыменований, и важных в связи с выходом D7).
[spoiler]
PHP 5.3 — В PHP 5й версии появилась возможность возвращать из методов и функций объект. Это позволяет использовать цепочки вызовов.
Самое важное новшество в ZE 2.0 – это новая объектная модель. К примеру в Zend Engine 1.0 (PHP 4) нельзя было использовать статические поля классов, содержащие объекты. Да и вообще много чего было нельзя, включая цепочку вызовов методов $object->method()->method(). А если вспомнить PHP 3.0 (но лучше не надо ), то там вообще процедурный стиль, и объектов не было.
Кстати, именно в Zend Engine 2.0 появился новый синтаксис обращения к символам строки:
$str1 = $str2 = "";
$str1{0} = 'a';
$str2[0] = 'a'; // такой синтаксис для строк
// уже давно объявлен как устаревший
Это сделано для того, чтобы избежать ошибок. К примеру, в приведенном выше примере $str1 станет строкой "a", а $str2 станет массивом array( 0 => "a" )
— Не совсем по теме, но важное доступное улучшение: у тернарного оператора есть теперь сокращенный вид: ?:.
Начиная с версии PHP 5.3 также стало возможным не писать среднюю часть тернарного оператора. Выражение expr1 ?: expr3 возвращает expr1 если expr1 имеет значение TRUE, и expr3 в другом случае.
— Добавлена возможность разыменования массивов, возвращаемых функциями. Например:
foo()[0]
$foo->bar()[0]
— Добавлена возможность получения доступа к члену класса при создании экземпляра. Например:
(new Foo)->method()
(new Foo)->property
(new Foo)[0]
— Теперь поддерживается такой синтаксис: Class::{expr}().
class A {
static function foo() {
echo "Hello world!\n";
}
}
$x = "f";
$y = "o";
A::{$x.$y.$y}();
— Новый тип передаваемого параметра метода/функции Callable, такой аргумент должен быть вызываемым (т.е. удовлетворять условию is_callable($arg, false))
Например:
function foo(callable $do) {
}
foo("strcmp");
foo(function() {});
$o = new ArrayObject();
foo(array($o, "count");
Как видите, в 5.4 много интересного, но использовать это все пока нельзя. Для решения таких задач в 5.3 придется создавать вспомогательные переменные.
К сожалению, как показывает практика, повсеместное внедрение новых версий PHP на серверах в глобальном масштабе – процесс затяжной, и во многом зависит от крупных игроков рынка, таких, которым несомненно является компания Битрикс.
Итог . Мы в данный момент работаем по версии 5.3, не смотря на то, что на сервере я установил 5.4. Поэтому конструкции из 5.4 нужно знать, но использовать пока нельзя, т.к. на хостах в интернете почти везде пока 5.3!
И на последок пример из жизни :
Этот кусок кода работал у нас на сервере, т.к. у нас 5.4 (я установил эту версию, т.к. у нее значительно повышена производительность, порядка 30-40%, как говорил недавно Расмус Лердорф, плюс это и заметно). Тем не менее писать нужно на 5.3!
Итак следующий код не вызывал у нас проблем на ТЕСТОВОМ рабочем сервере (см. current($vendor)[ '...' ], это доступно с 5.4)
Если данный код сразу был бы написан с учетом 5.3 - проблему совместимости удалось бы избежать.
На самом деле совместимость – это краеугольный камень всех программных систем. Важность совместимости бесспорна, но на ее поддержание уходит не мало сил. Возьмите историю с браузером IE7-8, который в мучениях приходится поддерживать некоторым верстальщикам до сих пор. Либо возьмите историю битрикса, «исторические хвосты» которой из-за поддержания совместимости платформы не давали системе развиваться. Об этом прямо сказано в описании нового ядра D7 на сайте битрикса:
Принцип совместимости, от которого компания "1С-Битрикс" не имеет права отказаться, обязывал выполнять большой объём работ, не направленных непосредственно на развитие Bitrix Framework. Это прямо влияло на скорость и качество разработки самой платформы, и косвенно влияло на распространение продуктов компании на рынке.
UPD1. Мы для себя выбрали этот путь, пока повсеместность 5.4 не установится. Но когда она установится, все наши проекты, написанные на 5.3 будут работать и на 5.4. И тогда мы уже повысим минимальную планку до 5.4
Почему нельзя? Если битрикс использует возможности 5.3 (а сделано это как компромисс между возможностями и совместимостью с максимальным количеством хостингов), но на сервере 5.5 - почему нельзя использовать возможности 5.5?
Зацепин Евгений, вы про частный случай. Обычно когда разрабатываешь рядовой проект, лучше его делать на 5.3, т.к. не известно за ранее, куда он переедет. Это что-то типа кросс-браузерности, цель - чтобы везде работало. А если это отдельный проект, и вы сами установили туда 5.5, то чего же нельзя - используйте. Только для переезда в другое место (если это потребуется) требования к хостингу/серверному окружению возрастет, и кол-во мест для переезда существенно сузиться.
Чебан Валерий, полностью согласен - если проект разрабатывается рядовой - с целью отдать в руки заказчика - необходимо поддерживать максимальную совместимость. Просто была непонятна такая категоричность в посте ) Вообще после 5.3, в котором ввели неймспейсы - в 5.4 и 5.5, таких существенных изменений нет, и зачастую вполне можно обойтись без дополнительных возможностей, но если изначально известно - что проект будет работать на выделенном сервере(так было у нас с последним проектом - был необходим mysql 5.6, попутно и версию php выбирали сами) - то можно себя не ограничивать.
Чебан Валерий, а может на windows сервер переедет где вообще не стоит php, заранее написать под .net что-ли? Это уже задача того кто переносит проект, а не разработчика.
Разработчик должен пользоваться всеми доступными средствами и возможностями, и не думать об возможном переносе. Другое дело БУC, конечно.
Зацепин Евгений, вы молодцы, что взяли на себя эти риски и решили использовать 5.5) это достойно похвалы) но опять же, что вам помешало писать в стиле 5.3, дабы везде работало? это ведь в действительности не трудно, нужно просто знать, что можно, а что нет. Это я в статье и осветил. Т.е. я хочу понять, это у вас был осознанный и продуманный выбор, лишиться совместимости с 5.3, основанный на необходимости, либо только ради того, чтобы была последняя версия PHP?
Чебан Валерий, да нет, соблюдать возможности 5.3 совсем не сложно - благо и в phpstorm выставляется уровень версии для инспекции кода. Просто учитывая другие требования к площадке(версия mysql, а конкретно - нужна работа с геометрией) - этот проект изначально рассчитан под выделенный сервер/vds и не заработает на обычном хостинге. В этом случае какой смысл искусственно ограничивать версию php?
Зацепин Евгений, я с вами согласен, конкретно в вашем отдельном примере вы поступили верно, ведь вы сами берете на себя поддержку vds и установку новой версии 5.5. Но согласитесь, это скорее исключение, чем правило. Тем более писать в стиле 5.3 совершенно не трудно, а для рядовых проектов - это обязательно и от спасает от несовместимости итоговой площадки. Мы для себя выбрали этот путь, пока повсеместность 5.4 не установится. Но когда она установится, все наши проекты, написанные на 5.3 будут работать и на 5.4. И тогда мы уже повысим минимальную планку до 5.4
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».