- 17, May 2024
- #1
Я разместил это на других форумах, но я собираюсь разместить это и здесь, так как мне просто очень интересно услышать, что думают другие и каков ваш опыт работы с этим на данный момент.
Мне просто любопытно - обновив свой сервер до PHP 7.1 - сколько других людей погрузились в его развертывание в реальных условиях.
Учитывая, что по состоянию на 31 декабря 2016 года ВСЯ разработка ветки 5.x официально завершилась, за исключением исправлений ошибок безопасности, и ей грозит конец жизни (то есть никаких обновлений безопасности) почти ровно через два года, это кажется безрассудным и совершенно глупым НЕ делать этого.
сейчас делаю переход. Но с другой стороны, использование устаревших версий с известными ошибками безопасности, похоже, является продолжающимся увлечением среди ленивых, слабоумных и просто подлых мошенников.
Похоже, что некоторые люди хотят, чтобы веб-программы написали один раз и забыли, но, честно говоря, это никогда не было справедливо ни для одного программного обеспечения.
Это кажется смехотворно ошибочным предположением, и именно поэтому ТАК много компаний, похоже, зацикливаются на таких вещах, как «мы уже знали это, почему вы все еще это делаете! Нам в течение ДЕСЯТИЛЕТИЯ говорили прекратить это делать». !"
Таким образом, мой собственный переход был относительно безобидным, поскольку если в 5.6 он работает без предупреждений, то и в 7 он запустится без ошибок.
Я все еще оцениваю свои кодовые базы, чтобы увидеть, какие/где изменения и улучшения можно/нужно использовать, просто чтобы еще больше сэкономить на моем хостинге. Для меня настроить его и запустить было несложно, поскольку, опять же, на помощь пришел HowToForge.
Я использую Debian 8.4 с ISPconfig 3, поэтому после «обновления apt-get; обновления apt-get» все прошло довольно чисто, несмотря на то, что мне пришлось собирать его из исходных кодов, поскольку Debian еще не создал для него официальный пакет.
и У меня есть недоверие к «пользовательским репозиториям». Единственная проблема заключается в том, что ISPConfig не любит выбирать PHP-FPM, выдавая 500 ошибок (кажется, Apache все еще ищет FPM PHP 5), но fastCGI все равно вызывает PHP-FPM, так как это то, что есть, поэтому я действительно не понимаю, в чем этот выбор ISPConfig делает.
Было намного проще в домене на том же сервере, который я настроил непосредственно в файлах Apache .conf. Также интересны мнения об изменениях и улучшениях языка - и я говорю о более тонких вещах, а не об очевидных: «Ну, пора уже избавиться от ерунды mysql_!». Хотя, опять же, было бы ЗАМЕЧАТЕЛЬНО, если бы они взяли на вооружение тренировочные колеса mysqli, чтобы слабоумные дураки, которые не могут смириться с тем, что «методология mysql_ плоха», перестали сходить с ума, используя ту же самую тупую чушь под mysqli. Изменения, которые мне нравятся, довольно просты. Определение массива немного запоздало.
DEFINE удобен, когда вам нужно, чтобы значения были неприкосновенными после установки и не давали летать фиолетовой рыбе в области видимости.
Возможность сделать их массивами? Прекрасный. Объединение значений Null — это здорово: больше не нужно возиться с isset, если вы просто хотите иметь альтернативное значение, когда оно не так.
Ты только
Точно так же оператор космического корабля — еще одно удобное сокращение для общей операции.
заменяющее троичную операцию:
Это одна из основных причин ошибок И возможных дыр в безопасности, и это то, с чем «настоящий» язык программирования, такой как C, никогда не столкнется.
Поскольку в версии 7.0 нам предоставили типизацию, также приятно, что в версии 7.1 появилась возможность использования void, чтобы память не тратилась зря на выделение пространства или случайную попытку вернуть значения из функций, которые не возвращают значения.
(что отличает Modula и Pascal, называя их процедурами, а не функциями) Мне также нравится, что объявления типов функций выполнены в стиле Вирта; приведение типа результата ПОСЛЕ имени функции и параметров.
хотя и добавили указанную функциональность в язык, если не считать замены «функции», куда еще они собирались ее поместить? Обобщающий «итерируемый» тип является своего рода обязательным, я думаю, теперь, когда у нас есть приведение типов, так что хорошо, что в 7.1 его добавили.
Если элемент является arrayTraversable - НЕЗАВИСИМО от того, является ли это фактическим массивом, вы можете использовать для него это приведение типов к параметрам и результатам.
ЧУВСТВУЕТ, что в этом нет необходимости, но, учитывая кошмар попытки добавить НАДЛЕЖАЩЕЕ приведение типов к языку, который более десяти лет существовал без концепции, это имеет смысл.
Я до сих пор не уверен, что это приложение для анонимных классов, но похоже, что фанаты изменчивости JavaScript пытаются перетащить свой мусор в PHP, потому что им не нравится, насколько близко к тому, как НАСТОЯЩИЕ ООП-языки делают вещи так же, как «расширяет» . Мне придется сесть и написать что-нибудь, чтобы действительно использовать это, чтобы посмотреть, смогу ли я вообще найти для этого причину.
Точно так же я не уверен, что понимаю, для чего вообще предназначено замыкание::call, но это похоже на то, что я, как человек, изучавший объекты в Smalltalk, Modula и Object Pascal, НИКОГДА не стал бы делать.
. Но мне не нравится «определение» закрытия, современное программирование, кажется, пришло из 1960-х годов и плохо переведено с финского на японский, а затем на английский, так что...
Запись строки кода Unicode? Опять же, почему этого вообще не было в языке?!? Я не заинтересован в функциональности initlChar, так как не уверен, зачем вам ее использовать (а тем более тратить на нее библиотечное пространство).
Доход от генераторов тоже хорошая идея; готово, СКАЖИТЕ, готово.
к сожалению, как бы мне ни нравились генераторы, когда они были представлены в версии 5.5, и они кажутся хорошей идеей, я еще не встречал реального сценария, где эта функциональность ДЕЙСТВИТЕЛЬНО кажется полезной; даже если внутри таких вещей, как операции выборки SQL, они представляют собой репликацию 1: 1 того, как они работают.
дело в том, что PHP предоставляет все это, и это единственный тип данных, которым я бы манипулировал таким образом.
Передача другим генераторам с использованием «от» (так называемое делегирование генератора) беспокоит меня с точки зрения поощрения спагетти-кода, но в то же время для больших задач разбиение одной функции на множество может помочь с ясностью кода.
Я разыгрываю карту «подождем и посмотрим», чем это обернется. Десериализовать? Обычно я не манипулирую данными таким образом, поэтому не уверен, что когда-нибудь буду им пользоваться... Кроме того, я не в восторге от пространств имен, поэтому не уверен, что меня волнуют их изменения в нем.
Для меня это то, что если у вас есть объекты И область действия функции, зачем вам это нужно?!? тем более, что, поскольку они могут изолировать область действия, но на самом деле не ОГРАНИЧИВАЮТ ее, какой в этом смысл? Помимо того, что это набор костылей для людей, пришедших с Java, поскольку Oracle продолжает свою тенденцию «давайте уничтожим ВСЕ, что мы купили у Sun»… Как поклонник языка вирт и ассемблера, мне очень нравится intDiv, но, черт возьми, мне бы хотелось, чтобы это был ОПЕРАТОР, а не функция.
Я имею в виду:
$а = intdiv(5, 2); // $a теперь равно 2
это «мило» и все такое, но было бы так сложно скопировать из языков семейства Вирт, используя СЛОВО в качестве операции? Я имею в виду, что в Паскале или Модуле то же самое:
а := 5 дел 2; { а теперь 2 }
Так что мне нравится эта идея, она ОЧЕНЬ запоздала, когда дело доходит до избавления от бесконечного бессмысленного тупого «пола» в стиле C каждый раз, когда вы что-то делаете.
но реализацию можно было бы немного почистить.
Это должна быть конструкция оператора/языка, а НЕ функция! ПРОСТО как/или %.
Переопределение массивов в session_start интересно, но я не совсем понимаю, ПОЧЕМУ вы это делаете - но возможно, что, поскольку я использую конструкцию «один индекс, чтобы управлять ими всеми», каждая страница и доступ пользователей на моем сайте маршрутизируются всего лишь через ОДИН index.php.
Если бы несколько .php были ориентированы на пользователя, я предположил, что их можно было бы использовать для отслеживания таких вещей, как, например, какой из них запускался последним.
preg_replace_callback_array — мощный инструмент, который может привести к более чистому коду, но он кажется достаточно сложным, и я вижу, как многие люди злятся по этому поводу.
Конечно, мы говорим о регулярных выражениях, так что, поскольку это уже так, один дополнительный поворот ножа является нормой.
Исправление list() для ArrayAccess было еще одним исправлением, но PHP 7.1 делает кое-что НАМНОГО более интересное с list(), оно добавляет возможность доступа к индексам, поэтому вы можете назначать ассоциативные массивы непосредственно переменным - что означает, что вы можете игнорировать некоторые, в частности, обращаются к другим индексам напрямую, вместо того, чтобы создавать переменную для КАЖДОЙ записи в массиве, который вы назначаете list().
Хотя в этот момент я начинаю задаваться вопросом, не является ли оператор типаbindParam, основанный на индексах, плохой идеей.
но новая деструктуризация массива в PHP 7.1 в этом отношении довольно крутая.
отрицательные смещения строк.
Раньше, если вы передавали отрицательное смещение строки, оно рассматривалось как ноль.
СЕЙЧАС? ЕСЛИ вы сказали $a[-2], вы получите второй символ с КОНЦА строки.
УДОБНО — чертовски лучше, чем играть с substrr, — но может вызвать проблемы с миграцией.
В версии 7.1 поддержка push-уведомлений CURL HTTP/2 действительно открывает двери для множества вещей, которые в конечном итоге вам придется либо перебирать с помощью сокетов самостоятельно, либо искать что-то вроде C для обработки.
Я еще не использовал его, и на самом деле он не считается важной функцией, но мне интересно, может ли он стать одним из тех бесшумных изменений в правилах игры, как это было с Microsoft.XMLHTTP.
может остаться незамеченным в течение нескольких лет, пока кто-то дает ему запоминающееся имя, например AJAX.
Константы классов были интересны с самого начала, но отсутствие средств управления их областью действия свело на нет большую часть полезности, поскольку в этот момент их просто помещали в глобальное DEFINE - поэтому мне нравится, что они добавили возможность устанавливать их как частные, защищенные.
и общественность. В версии 7.1 также добавлена возможность перехватывать несколько типов исключений.
В прошлом у меня было несколько случаев, когда мне хотелось, чтобы это было возможно, так что хорошо, что это наконец-то получилось! Что касается всего того, что устарело, удалено и исключено, я по большей части одобряю.
Единственное, что меня немного смущает, — это удаление опции «salt» из пароля_hash.
Похоже, они думают, что значение, сгенерированное системой, на самом деле будет более безопасным, чем значение, добавленное разработчиком, хотя я думал, что смысл этого в том, чтобы наложить пользовательское значение НАД системой, сгенерированное в качестве дополнительного шага.
В целом я не в восторге от пароля_hash, я все еще использую hash(), поскольку он предлагает поддержку SHA512 и Whirlpool.
Мой опыт работы с базами данных за последние три с половиной десятилетия научил меня никогда не доверять генерируемым системой хеш-кодам или криптологии, выбранной на языке - однако, похоже, именно это разработчики PHP на самом деле активно поощряют людей делать.
В любом случае, это мои взгляды на это.
мнения? Что вы, ребята, думаете об этом? Уже сделали решительный шаг? Как это прошло для вас? Есть ли проблемы с его установкой, которыми вы хотели бы поделиться?
Это важная тема, и чем раньше мы начнем говорить о «смерти 5.x», тем лучше, тем более, что 5.6 теперь официально находится в коме и находится на жизнеобеспечении, что касается группы PHP.
Мне просто любопытно - обновив свой сервер до PHP 7.1 - сколько других людей погрузились в его развертывание в реальных условиях.
Учитывая, что по состоянию на 31 декабря 2016 года ВСЯ разработка ветки 5.x официально завершилась, за исключением исправлений ошибок безопасности, и ей грозит конец жизни (то есть никаких обновлений безопасности) почти ровно через два года, это кажется безрассудным и совершенно глупым НЕ делать этого.
сейчас делаю переход. Но с другой стороны, использование устаревших версий с известными ошибками безопасности, похоже, является продолжающимся увлечением среди ленивых, слабоумных и просто подлых мошенников.
Похоже, что некоторые люди хотят, чтобы веб-программы написали один раз и забыли, но, честно говоря, это никогда не было справедливо ни для одного программного обеспечения.
Это кажется смехотворно ошибочным предположением, и именно поэтому ТАК много компаний, похоже, зацикливаются на таких вещах, как «мы уже знали это, почему вы все еще это делаете! Нам в течение ДЕСЯТИЛЕТИЯ говорили прекратить это делать». !"
Таким образом, мой собственный переход был относительно безобидным, поскольку если в 5.6 он работает без предупреждений, то и в 7 он запустится без ошибок.
Я все еще оцениваю свои кодовые базы, чтобы увидеть, какие/где изменения и улучшения можно/нужно использовать, просто чтобы еще больше сэкономить на моем хостинге. Для меня настроить его и запустить было несложно, поскольку, опять же, на помощь пришел HowToForge.
Я использую Debian 8.4 с ISPconfig 3, поэтому после «обновления apt-get; обновления apt-get» все прошло довольно чисто, несмотря на то, что мне пришлось собирать его из исходных кодов, поскольку Debian еще не создал для него официальный пакет.
и У меня есть недоверие к «пользовательским репозиториям». Единственная проблема заключается в том, что ISPConfig не любит выбирать PHP-FPM, выдавая 500 ошибок (кажется, Apache все еще ищет FPM PHP 5), но fastCGI все равно вызывает PHP-FPM, так как это то, что есть, поэтому я действительно не понимаю, в чем этот выбор ISPConfig делает.
Было намного проще в домене на том же сервере, который я настроил непосредственно в файлах Apache .conf. Также интересны мнения об изменениях и улучшениях языка - и я говорю о более тонких вещах, а не об очевидных: «Ну, пора уже избавиться от ерунды mysql_!». Хотя, опять же, было бы ЗАМЕЧАТЕЛЬНО, если бы они взяли на вооружение тренировочные колеса mysqli, чтобы слабоумные дураки, которые не могут смириться с тем, что «методология mysql_ плоха», перестали сходить с ума, используя ту же самую тупую чушь под mysqli. Изменения, которые мне нравятся, довольно просты. Определение массива немного запоздало.
DEFINE удобен, когда вам нужно, чтобы значения были неприкосновенными после установки и не давали летать фиолетовой рыбе в области видимости.
Возможность сделать их массивами? Прекрасный. Объединение значений Null — это здорово: больше не нужно возиться с isset, если вы просто хотите иметь альтернативное значение, когда оно не так.
Ты только
$test = [
[ '007', 'Jimbo' ],
[ '711', 'Apu' ]
];
foreach ($test as [ $id, $name ]) {
Точно так же оператор космического корабля — еще одно удобное сокращение для общей операции.
заменяющее троичную операцию:
$gtl= $a <=> b; $gtl = $a < $b ? -1 : ($a > b ? 1 : 0); Это одна из основных причин ошибок И возможных дыр в безопасности, и это то, с чем «настоящий» язык программирования, такой как C, никогда не столкнется.
Поскольку в версии 7.0 нам предоставили типизацию, также приятно, что в версии 7.1 появилась возможность использования void, чтобы память не тратилась зря на выделение пространства или случайную попытку вернуть значения из функций, которые не возвращают значения.
(что отличает Modula и Pascal, называя их процедурами, а не функциями) Мне также нравится, что объявления типов функций выполнены в стиле Вирта; приведение типа результата ПОСЛЕ имени функции и параметров.
хотя и добавили указанную функциональность в язык, если не считать замены «функции», куда еще они собирались ее поместить? Обобщающий «итерируемый» тип является своего рода обязательным, я думаю, теперь, когда у нас есть приведение типов, так что хорошо, что в 7.1 его добавили.
Если элемент является arrayTraversable - НЕЗАВИСИМО от того, является ли это фактическим массивом, вы можете использовать для него это приведение типов к параметрам и результатам.
ЧУВСТВУЕТ, что в этом нет необходимости, но, учитывая кошмар попытки добавить НАДЛЕЖАЩЕЕ приведение типов к языку, который более десяти лет существовал без концепции, это имеет смысл.
Я до сих пор не уверен, что это приложение для анонимных классов, но похоже, что фанаты изменчивости JavaScript пытаются перетащить свой мусор в PHP, потому что им не нравится, насколько близко к тому, как НАСТОЯЩИЕ ООП-языки делают вещи так же, как «расширяет» . Мне придется сесть и написать что-нибудь, чтобы действительно использовать это, чтобы посмотреть, смогу ли я вообще найти для этого причину.
Точно так же я не уверен, что понимаю, для чего вообще предназначено замыкание::call, но это похоже на то, что я, как человек, изучавший объекты в Smalltalk, Modula и Object Pascal, НИКОГДА не стал бы делать.
. Но мне не нравится «определение» закрытия, современное программирование, кажется, пришло из 1960-х годов и плохо переведено с финского на японский, а затем на английский, так что...
Запись строки кода Unicode? Опять же, почему этого вообще не было в языке?!? Я не заинтересован в функциональности initlChar, так как не уверен, зачем вам ее использовать (а тем более тратить на нее библиотечное пространство).
Доход от генераторов тоже хорошая идея; готово, СКАЖИТЕ, готово.
к сожалению, как бы мне ни нравились генераторы, когда они были представлены в версии 5.5, и они кажутся хорошей идеей, я еще не встречал реального сценария, где эта функциональность ДЕЙСТВИТЕЛЬНО кажется полезной; даже если внутри таких вещей, как операции выборки SQL, они представляют собой репликацию 1: 1 того, как они работают.
дело в том, что PHP предоставляет все это, и это единственный тип данных, которым я бы манипулировал таким образом.
Передача другим генераторам с использованием «от» (так называемое делегирование генератора) беспокоит меня с точки зрения поощрения спагетти-кода, но в то же время для больших задач разбиение одной функции на множество может помочь с ясностью кода.
Я разыгрываю карту «подождем и посмотрим», чем это обернется. Десериализовать? Обычно я не манипулирую данными таким образом, поэтому не уверен, что когда-нибудь буду им пользоваться... Кроме того, я не в восторге от пространств имен, поэтому не уверен, что меня волнуют их изменения в нем.
Для меня это то, что если у вас есть объекты И область действия функции, зачем вам это нужно?!? тем более, что, поскольку они могут изолировать область действия, но на самом деле не ОГРАНИЧИВАЮТ ее, какой в этом смысл? Помимо того, что это набор костылей для людей, пришедших с Java, поскольку Oracle продолжает свою тенденцию «давайте уничтожим ВСЕ, что мы купили у Sun»… Как поклонник языка вирт и ассемблера, мне очень нравится intDiv, но, черт возьми, мне бы хотелось, чтобы это был ОПЕРАТОР, а не функция.
Я имею в виду:
$а = intdiv(5, 2); // $a теперь равно 2
это «мило» и все такое, но было бы так сложно скопировать из языков семейства Вирт, используя СЛОВО в качестве операции? Я имею в виду, что в Паскале или Модуле то же самое:
а := 5 дел 2; { а теперь 2 }
Так что мне нравится эта идея, она ОЧЕНЬ запоздала, когда дело доходит до избавления от бесконечного бессмысленного тупого «пола» в стиле C каждый раз, когда вы что-то делаете.
но реализацию можно было бы немного почистить.
Это должна быть конструкция оператора/языка, а НЕ функция! ПРОСТО как/или %.
Переопределение массивов в session_start интересно, но я не совсем понимаю, ПОЧЕМУ вы это делаете - но возможно, что, поскольку я использую конструкцию «один индекс, чтобы управлять ими всеми», каждая страница и доступ пользователей на моем сайте маршрутизируются всего лишь через ОДИН index.php.
Если бы несколько .php были ориентированы на пользователя, я предположил, что их можно было бы использовать для отслеживания таких вещей, как, например, какой из них запускался последним.
preg_replace_callback_array — мощный инструмент, который может привести к более чистому коду, но он кажется достаточно сложным, и я вижу, как многие люди злятся по этому поводу.
Конечно, мы говорим о регулярных выражениях, так что, поскольку это уже так, один дополнительный поворот ножа является нормой.
Исправление list() для ArrayAccess было еще одним исправлением, но PHP 7.1 делает кое-что НАМНОГО более интересное с list(), оно добавляет возможность доступа к индексам, поэтому вы можете назначать ассоциативные массивы непосредственно переменным - что означает, что вы можете игнорировать некоторые, в частности, обращаются к другим индексам напрямую, вместо того, чтобы создавать переменную для КАЖДОЙ записи в массиве, который вы назначаете list().
Хотя в этот момент я начинаю задаваться вопросом, не является ли оператор типаbindParam, основанный на индексах, плохой идеей.
но новая деструктуризация массива в PHP 7.1 в этом отношении довольно крутая.
$name = $_POST['username'] ?? 'guest';отрицательные смещения строк.
Раньше, если вы передавали отрицательное смещение строки, оно рассматривалось как ноль.
СЕЙЧАС? ЕСЛИ вы сказали $a[-2], вы получите второй символ с КОНЦА строки.
УДОБНО — чертовски лучше, чем играть с substrr, — но может вызвать проблемы с миграцией.
В версии 7.1 поддержка push-уведомлений CURL HTTP/2 действительно открывает двери для множества вещей, которые в конечном итоге вам придется либо перебирать с помощью сокетов самостоятельно, либо искать что-то вроде C для обработки.
Я еще не использовал его, и на самом деле он не считается важной функцией, но мне интересно, может ли он стать одним из тех бесшумных изменений в правилах игры, как это было с Microsoft.XMLHTTP.
может остаться незамеченным в течение нескольких лет, пока кто-то дает ему запоминающееся имя, например AJAX.
Константы классов были интересны с самого начала, но отсутствие средств управления их областью действия свело на нет большую часть полезности, поскольку в этот момент их просто помещали в глобальное DEFINE - поэтому мне нравится, что они добавили возможность устанавливать их как частные, защищенные.
и общественность. В версии 7.1 также добавлена возможность перехватывать несколько типов исключений.
В прошлом у меня было несколько случаев, когда мне хотелось, чтобы это было возможно, так что хорошо, что это наконец-то получилось! Что касается всего того, что устарело, удалено и исключено, я по большей части одобряю.
Единственное, что меня немного смущает, — это удаление опции «salt» из пароля_hash.
Похоже, они думают, что значение, сгенерированное системой, на самом деле будет более безопасным, чем значение, добавленное разработчиком, хотя я думал, что смысл этого в том, чтобы наложить пользовательское значение НАД системой, сгенерированное в качестве дополнительного шага.
В целом я не в восторге от пароля_hash, я все еще использую hash(), поскольку он предлагает поддержку SHA512 и Whirlpool.
Мой опыт работы с базами данных за последние три с половиной десятилетия научил меня никогда не доверять генерируемым системой хеш-кодам или криптологии, выбранной на языке - однако, похоже, именно это разработчики PHP на самом деле активно поощряют людей делать.
В любом случае, это мои взгляды на это.
мнения? Что вы, ребята, думаете об этом? Уже сделали решительный шаг? Как это прошло для вас? Есть ли проблемы с его установкой, которыми вы хотели бы поделиться?
Это важная тема, и чем раньше мы начнем говорить о «смерти 5.x», тем лучше, тем более, что 5.6 теперь официально находится в коме и находится на жизнеобеспечении, что касается группы PHP.
