Pull to refresh

Comments 62

Ура, товарищи! Хотелось бы увидеть тесты производительности на популярных cms и фреймворках.
это жирный плюс :) спасибище!
Ура! Осталось подождать всего-то тыщу лет, пока эта версия докатиться до продакшн-серверов и виртуальных хостингов.
Мне кажется, что переползание начнётся сразу по релизу, уж очень соблазнительно получить прирост производительности даром. Конечно, если не выплывет какого-нибудь крупного косяка. На мой взгляд, изменения менее существенны, чем при переходе с 5.2 на 5.3.
Не забывайте о куче pecl и zend расширений, которые многим нужны.
На мой взгляд, изменения менее существенны, чем при переходе с 5.2 на 5.3.
Менее существенны в смысле принципиальности и глобальности, но переписывать надо достаточно много кода, ряд проектов мы просто не будем переводить на 7-ку, ибо никто это не оплатит — слишком дорого.
Было бы неплохо, что бы появился какой-то анализатор кода, который будет указывать на то что надо поправить, но надежды на это немного.
Вроде ж планировали еще и автоматический фиксер кода, нет?
Да вроде особо нечего переписывать-то. Надо очень странный код писать, чтобы изменения его затронули. У меня все юнит-тесты прошли на альфе. Правда, opcache иногда сегфолтился, но это другая проблема.
unset внутри цикла никогда не делали?
Кстати, насколько я понимаю, unset(), сделанный внутри цикла, сработает все равно. Просто эти изменения будут не видны внутри цикла. А снаружи — пожалуйста. Или нет?
А это, как уже верно заметил FractalizeR, ложь и провокация. Все работает, как и прежде:

codepad.viper-7.com/gT7CyS

Только что проверил на свежем master, результат тот же. Копия используется «внутри».
UFO just landed and posted this here
А в этой версии название функций привели к единому стилю, порядку аргументов?
Да вряд ли приведут. Это поломает огромное количество существующего кода, а тогда PHP7 нафиг никому не нужен будет.
От него и сейчас то все уходят.
Есть на это RFC и совместимость он не ломает. Старые названия функций остаются и добавляются новые более однородные названия. В 7.0 он уже не войдет, но в какой-нибудь релизе 7.1+ вполне могут что-то такое сделать.
Т.е. они добавят ещё «стопицот» новых функций? Ужас. Читать чей нибудь PHP код вообще будет невозможно.
Добавят, а стопицот старых объявят устаревшими и выпилят через пару релизов. А вы как хотели поменять имена и сохранить обратную совместимость одновременно?
Никак. У них не получится, и никакие RFC не помогут.
Учитывая средний уровень PHP программистов, то никакие RFC и best-practices они читать не будут. Напишут код как нибудь, чтобы работало: насобирают кусков кода со stackoverflow и остального интернета. Это будет каша из старых функций, и новых. И такого кода будет не мало. И опять в кругах разработчиков PHP вспыхнут прения: ломать совместимость и удалять старые функции, или нет. И, в общем-то, я думаю Вы и сами понимаете какой выбор они сделают. Такой же, как на протяжении всех предыдущих лет.

Факты говорят иное. Например, mysql_ функции в 7.0 уже выпилили ровно таким же способом, и с 7й версии никакой каши mysql_/mysqli_ уже не будет.
UFO just landed and posted this here
Какая у Вас интересная логика. Во-первых, про себя я ничего не говорил. Во-вторых, почитайте хотя бы это. Кажется, на хабре даже где-то был её перевод. Сразу поймёте масштаб проблемы.

Cразу видно, что с крупными проектами Вы не работали. Если PHP комьюнити решится на такой шаг, то я с удовольствием посмотрю, насколько тяжело комьюнити дастся такой переход. За примерами далеко ходить не надо: Python'у, который чуточку менее популярный чем PHP, переход со второй версии на третью дался с большим трудом — до сих пор очень большое количество пакетов не поддерживают третью версию, а многие даже не собираются переписывать свои библиотеки.
Так не надо переписывать старые проекты и проблем не будет. Всего-то нужен LTS* релиз на основе последнего PHP 5 и всё, года через три-четыре будем вспоминать как ужасно раньше было :) (популярные библиотеки обновятся рано или поздно, а даже если что-то умрет, то большая любовь комьюнити к велосипедостроению довольно быстро заполнит освободившиеся ниши).

* так то уже всё есть www.zend.com/en/support-center/support/php-long-term-support, но на платной основе.
Про Python так же говорили. Как итог — я сейчас регулярно натыкаюсь на библиотеки, которые до сих пор не портированы на python3, и вряд ли будут. И ещё раз повторяю: таких библиотек очень много до сих пор. Есть люди, которые решили определённые задачи написав библиотеку, и выложили её в публичный доступ. Дальше они поддерживать их не будут, и вряд ли перепишут, а комьюнити, не факт что перепишет лучше. Пусть даже перепишет, вопрос во времени, которое им понадобится.

Давайте мы не будем гадать. Я Вам привёл пример языка, где подобный переход (хотя на самом деле, между python2 и python3 разница не такая большая, как планируемая между PHP5 и PHP7) длится уже 8 год, а в случае с PHP всё гораздо хуже, как из-за большего количества функций языка, так и из-за среднего уровня людей на нём пишущих приложения. Можете мне рассказать success story хоть одного языка, в котором подобное прокатило? Да, наверняка останется достаточное количество достойных программистов, фанатов языка которые всё напишут. Вопрос только в том, сколько времени у них это займёт, и сколько будет написано жуткого кода во время этого периода.

Так вот, отходя плавно от полемики в которую Вы меня пытаетесь увести: разговор был про переписывание функций, которое планируется к следующим релизам. Вопрос: сколько будет написано пахнущего кода во время этого перехода? А во время следующей «чистки»? И ведь кому-то это придётся поддерживать.
Вообще то с точки зрения библиотек, PHP5.6 и PHP7 не отличаются практически, потому что обратная совместимость сохранена на уровне языка. Обратная совместимость потеряна только на уровне внутренностей реализации интерпретатора. А в питоне2 и 3 потеряна обратная совместимость на уровне языка. Так что вы что-то не то сравниваете.
Подождите. Вы опять пытаетесь меня увести в сторону. Я изначально написал:

Т.е. они добавят ещё «стопицот» новых функций? Ужас. Читать чей нибудь PHP код вообще будет невозможно.


Т.е. планируется добавить пачку новых функций, которые повторяют функционал других. Меняется только название и порядок/количество аргументов. Будет снова гора кода, где часть функций deprecated, а часть «новые».
Вообще этот ужас с количеством функций языка удручает.

В python особо не потеряна обратная совместимость. Не так много на самом деле изменилось. Ну, это так по мне. Для меня переход с 2 на 3 версию дался легко.
Не очень понимаю чем может удручать поэтапное эволюционирование языка?

Я же указал вам на что у сообщества PHP не будет проблем с переходом популярных(и не очень) библиотек на новые версии языка, так как нет потери обратной совместимости, в отличии от питона, пример которого вы привели.

Что касается кода, не высокого качества, то его количество не измениться. Но хороший код станет писать приятнее и удобней.
революция vs эволюция всегда было холиварной темой.

Что до функций — на самом деле не проблема нынче написать тулзу для автоматической миграции кода. Благо инструментарий для основы имеется.
> между python2 и python3 разница не такая большая, как планируемая между PHP5 и PHP7

Python не знаю, к сожалению, но судя по первым ссылкам в гугле (например,http://pythonworld.ru/osnovy/python2-vs-python3-razlichiya-sintaksisa.html) там вообще всё сломали и сделали по другому. PHP7 же это просто эволюция при том больше самого движка нежели синтаксиса (из того что выше не так много по настоящему критичного). Планируемое переименование функций проблем тоже не создает ибо можно автоматизировать генерацию алиасов на старые функции (я вообще не думаю что кто-то будет руками сидеть и все это переносить). Да и вообще переход с PHP4 на PHP5 был гораздо хуже.
UFO just landed and posted this here
> «ломать совместимость и удалять старые функции, или нет»

В таких случаях, так и напрашивается конструкция вида:

  use PHP5.3;
Нет уж, спасибо, не надо. Кушайте это в перле.

Если для конкретного проекта нужен php 5.3, никто не мешает его установить.
«Мусье не знает толк в извращениях» (ц)
PHP, наверное, хороший язык и вы все его любите. Но, черт, какой-же он нечитабельный. Сейчас работаю с одним проектом, у которого сервер написан полностью на PHP (программистами, которым пофиг на хорошие практики) и разобраться с ходу ни в чем не получается. Вообще интересно было бы почитать какой-нибудь материал про то, как писать maintainable PHP. Может кто-нибудь что-нибудь посоветует? Чем короче публикация — тем лучше. :)
Казалось бы, дело не в языке, а людях, пишущих код. Тем более вы сами про это же и пишете.
Когда в языке есть 10+ способов сделать одно и тоже, и выстрелить себе в ногу — это конечно способствует написанию хорошего кода. :)
Господа минусующие: у Вас есть что возразить по делу, или продолжите сливать мне карму, просто от обиды из-за фактов? Факты штука такая, против них не попрёшь.
Я вам не минусовал, но все же комментарий получается однобоким: если выкинуть все ЯП, позволяющие выстрелить в ногу и сделать что-то более, чем одним способом, то много ли останется чего-то приемлемого?
Понятно, что если код пишут люди, которым плевать на стандарты, практики и подходы к разработке на конкретном ЯП — то тут уже ничего не поможет (включая возможности и инструментарий самого ЯП).
Вы ошиблись: этот вопрос надо не мне задавать. У меня после написания кода на PHP остались сугубо негативные чувства, и я расскажу больше плохого, чем хорошего.
А знаете, расскажите. Только постарайтесь объективно. + уточните что и когда вы писали, насколько хорошо его знаете и на чем пишите в основном. Так, для статистики. Хотя бы на примере вот этого.
Заодно расскажите (я может плохо знаком с telnet или были другие особенности), почему вы из сокета читаете по одному чару?
UFO just landed and posted this here
В целом отличные изменения, кроме вот этих двух вещей, который вызывает только вопрос «ШТА?!»

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

Господа, как с этим жить? Теперь трейсы перестанут быть трейсами т.к. вызов функции с аргументами, показанными в трейсе, не всегда будет приводить к оригинальному результату.
Как итог, трейсам нельзя будет доверять. Как могли на такое пойти? Это же просто суицид-фича какая-то.

image

Далее

Во время итерирования массивов по значению, foreach теперь пользуется копией массива, и его изменения внутри цикла не повлияют на поведение цикла

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


Тоже неоднозначное изменение, которое в корне меняет концепцию foreach — если раньше это был обычный обход элементов массива либо по значению, либо по ссылке, то теперь это 2 совершенно разных вида циклов: один read-only, второй read-write.
В принципе, ничего не имею против, но стоило ли ради этого ломать обратную совместимость, даже если это касается такой странной практики, как изменение массива в момент его обхода?
А что странного в этой практике? Конечно, есть альтернативные способы написания, но удаление ненужных по какой-то логике элементов из массива при итерации вроде бы ничем не странное
foreach не делает исходный массив read-only. Изменения, произведенные над массивом внутри цикла будут видны после выхода из цикла. Можно пробовать, например, здесь: codepad.viper-7.com/pJ6KCf

<?php
	$array = [1, 2, 3];

foreach($array as $arg) {
  unset($array[0]);
}

var_dump($array);


Выведет массив из двух элементов, а не из трех.
Strict Standards: Only variables should be passed by reference
Я, конечно, за максимальный стрикт, но зачем он здесь нужен?
Ну передали результат «по-ссылке», не сохранится он нигде после вызова, ну и что?
Нет, надо городить промежуточные переменные.
Это указание, что, вероятно, в коде написано не то, что хотел написать разработчик. Это как присвоение в if: можно (в некоторых ЯП), но часто не то, что нужно.
Ну почему, в примере вполне реальный случай. Получить из функции массив, а из него только последний элемент.
Мы же сейчас про array_pop? Но ведь это не получение последнего элемента, это забирание элемента с вершины стека. Передавая по значению, теряется вообще смысл операции.
Это: 1. удаление элемента из стека, 2. получение этого элемента.
Меня может интересовать только этот элемент, а состояние остального стека нет.
В таком случае да, это не то, что нужно. Подошел бы end, но и он по ссылке хочет значение. Тут скорее вопрос к полноте и функциональности стандартного набора функций и ЯП, раз приходится писать свой вариант arr[count(arr) — 1] за его неимением.
по ссылке end хочет массив только потому что меняет указатель на текущий элемент списка (массивы же в php все еще списки). Не вижу в этом ничего такого, из-за чего нужно писать свою функцию, тем более покрывающую только часть сценариев. В то же время end влияет только на случаи когда код зависит от указателя на текущий элемент. Не забывайте что может быть и такое:

$arr = [1, 2, 3];
$arr[7] = 4; // мало ли, бывает

$end = end($arr); //4
$arr[count($arr)-1]; // Notice:  Undefined offset
Так я про end к тому, что он тоже позволяет получить элемент, но тоже с тем же подходом со Strict Standards. Т.е. в php есть две более-менее подходящие функции, но обе хотят ссылку. И ни одной, которым ссылка не нужна.
ясно, тут соглашусь. Хотя опять же, основное предназначение функции end — двигать указатель. Если вам так хочется получить последний элемент массива и не хочется париться из-за побочных эффектов то можно воспользоватьяся тем что пых копирует аргументы при передаче в функции (при записи, или в нашем случае, создании референса).

function last(array $arr) {
    // слава Copy-on-write
    return end($arr);
}

// лучше вообще юзать какие-нибудь коллекции
function first(array $arr) {
    return reset($arr);
}

function foo() {
    return [1, 2, 3, 4];
}

last(foo()); // 4
first(foo()); //1
Sign up to leave a comment.

Articles