How to become an author
Search
Write a publication
Pull to refresh

Comments 56

Расширение mysql больше недоступно

Как и memcached
This comment wasn’t rated yet0
насколько я понимаю внутренности поменялись гораздо сильнее чем сам язык. Как раз поэтому автор XCache написал что пока нет планов на версию для 7-ки.
This comment wasn’t rated yet0
что с memcached не так? на homebrew он устанавливается, только доступен из ветки dev-master
видимо выкатят стабильную версию после релиза самого php7
Total votes 3: ↑3 and ↓0+3
То есть, код
$array = [1,2,3];
foreach ( $array as $k=>&$v )
{
    $v = get_something_else(); // return 3 4 5
}
var_dump($array);

что в итоге даст?
This comment wasn’t rated yet0
с & совсем другое дело, тут работать также будет. Имеется ввиду такое:

$a = array(1,2,3);
$b = &$a;
foreach($a as $v) {
    echo "$v\n";
    unset($a[1]);
}
Total votes 2: ↑2 and ↓0+2
Понятно, спасибо. Делать unset() внутри foreach никогда не было безопасно.
Total votes 2: ↑2 and ↓0+2
Расскажите тогда, как стоит поступать в таких ситуациях?

$a = array("test"=>"1", "test2"=>2, "test3"=>3);
$needed = array("test", "test2");
foreach($a as $i => $v) {
    if(!in_array($i, $needed)) {
        unset($a[$i]);
    }   
}


Ну надо мне провалидировать что-то. Собирать новый массив?
Total votes 1: ↑1 and ↓0+1
Собирать новый массив?

Именно так.

$a = array("test"=>"1", "test2"=>2, "test3"=>3);
$needed = array("test", "test2");

$a = array_filter($a, function ($item) {
     return in_array($item, $needed);
});
Total votes 2: ↑2 and ↓0+2
Вы use($needed) забыли.
Total votes 2: ↑2 and ↓0+2
Наткнулся в комментариях на ещё один пост: http://habrahabr.ru/post/114899/

У меня прям все написанные исходники перед глазами пронеслись. Думал в такие моменты, что нужно больше спать, и переписывал на if-else.
This comment wasn’t rated yet0
Да, TheShock умеет «накинуть» :) Там же в комментах, вместо if-else
switch(true){
    case isCondFirst():
        value = valueFirst();
        break;
    case isCondSecond():
        value = valueSecond();
        break;
    case isCondThird():
        value = valueThird();
        break;
    default:
        value = valueDefault();
}


просто нечто.
This comment wasn’t rated yet0
Я конкретно эту ситуацию имею ввиду:

$a = ['test' => '1', 'test2' => 2, 'test3' => 3];
$filter = ['test', 'test2'];

$a = array_intersect_key($a, array_flip($filter));


Если ситуация отличается, то и решение может быть другое. Но вот в данном конкретном случае такой код лучше подойдёт, мне кажется. Как минимум, одной переменной меньше и используются встроенные функции, вместо реализации алгоритма вручную.
This comment wasn’t rated yet0
А что если?

$a = array(1,2,3);
foreach($a as $i => $v) {
    echo "$v\n";
    $a[$i] = $v * 2;
}

var_dump($a); // ???
This comment wasn’t rated yet0
какая полезная песочница. Я постоянно юзал sandbox.onlinephpfunctions.com
This comment wasn’t rated yet0
И мне нужен xdebug для отладки, а то без него ой как плохо отлаживать сложные прыжки в коде. Жду, когда они 2.4.0 в релиз выпустят.
Total votes 2: ↑2 and ↓0+2
Ну на сервере то отладка не пригодиться. Так что это не такая-уж проблема, хотя конечно неприятно разрабатывать на одном а деплоить на другой. Этот пост скорее мотиватор пофиксить у себя все E_STRICT чтобы потом боком не вылезли.
This comment wasn’t rated yet0
Я для себя придерживаюсь железного правила: 
ini_set("error_reporting",65535);
и чтобы не было ни одного уведомления в работе. Жаль только, такого очень трудно достичь используя чужие фреймворки.
Total votes 2: ↑1 and ↓10
UFO just landed and posted this here
Я имел в виду E_ALL и ещё один бит.
This comment wasn’t rated yet0
UFO just landed and posted this here
Версии должны быть одинаковыми, но расширению xdebug на продакшене не место, оно жутко тормозное
This comment wasn’t rated yet0
так они в PDO входят же, так что конечно
Total votes 1: ↑1 and ↓0+1
ext-pgsql работает без нареканий.
Total votes 1: ↑1 and ↓0+1
Для примера простой сайт на PHPixie заработал почти в три раза быстрее практически сравнившись со скоростью Phalcon на PHP 5.6, несколько сайтов на Wordpress показали стабильный прирост в скорости в два раза.

Странные какие-то сравнения. В два, в три раза… По сравнению с чем? Какие задачи сравнивались? Какие операции?
Если учесть, что в обычных сайтах основная часть времени уходит на запросы к БД, то непонятно, как смена версии PHP могла это ускорить. Или там на сайтах интегралы численными методами высчитываются?)
Total votes 5: ↑3 and ↓2+1
основная часть времени уходит на запросы к БД


это давно уже совсем не так, вот например бенчмарки от Techempower: www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=fortune&l=sg

По условиям теста запросов у каждого фреймворка получается столько же, но вот скорость сильно отличается
This comment wasn’t rated yet0
Сегфолтит семёрка пока по-страшному. Правят оперативно, но надо больше тестов. Прошу всех погонять свои проекты и заслать в багтрекер трейсы, дампы или, что вообще лучше всего, короткие кусочки кода, которые PHP валят.
This comment wasn’t rated yet0
Сейчас пишу новый проект на семерке. Стремно, но пишу. Пока что не словил ни единого бага, вылета и тд. Расширения спокойно собрал вручную, все что для проекта нужно — работает. Вот интересно что может быть аргументом против запуска нового проекта на РНР 7 на следующий день после его релиза.
This comment wasn’t rated yet0
Против проверки на тестовом сервере — ничего. Против выката на продакшн много чего. Как минимум стоит спланировать откат до 5.6 в деталях.
This comment wasn’t rated yet0
У меня коллеги как раз таки из-за сегфолтов php5.6 апнулись на семерку. hhvm как оказалось отвратительно работает с postgresql.

Это я к чему, для любого апдейта должны быть причины. Уж темболее если это апдейта на релиз кандидат или бетку.
This comment wasn’t rated yet0
Думаю, получить от 30% прироста производительности — хороший аргумент за переход на семёрку. Но делать это надо осторожно.
This comment wasn’t rated yet0
В общем и целом отлично. Код работать будет. Все сегфолты воспроизведены и закинуты в трекер. Большинство Расмус уже поправил.

Новых фич семёрки, конечно же, из за обратной совместимости, не используем пока.
This comment wasn’t rated yet0
интересно очень, дождусь релиза и запущу отдельный сервер с семеркой и налью часть трафа hotwork.ru померяю реальное ускорение
This comment wasn’t rated yet0
неужели у вас нет старых добрых нагрузочных тестов?
This comment wasn’t rated yet0
не применяли, в системе 100к суточных визитов, нагрузка растет плавно, поэтому гонять нагрузку в суточные 1млн визитов смысла особо нет
а ливануть пару тыс живого трафа на хорошее дело всегда можно ;)
This comment wasn’t rated yet0
Если только отсутствие нужных библиотек, совместимых с PHP 7.
Пока дойдете до релиза думаю что если «вдруг» что-то и появится внезапное, — то всё будет пофикшено.
This comment wasn’t rated yet0
на данный момент есть аж 2 инструмента что бы помочь быстрее мигрировать проекты на php7:

— github.com/Alexia/php7mar
— github.com/sstalle/php7cc

В принципе популярные фреймворки уже совместимы с PHP7. В частности у Symfony небыло никаких проблем.
This comment wasn’t rated yet0
Безумству храбрых поём мы песню, конечно. На ветке PHP7 постоянно находятся неприятные баги. Падения, зацикливания, утечки. Например описание сегодняшнего исправления такое: «try{ } finally{} can create infinite chains of exceptions».
Total votes 1: ↑1 and ↓0+1
А Вы злостный хейтер?) Тогда не портите радость другим, ее в мире не так много. Ну переходят и переходят, они же не конкуренты Вам.
This comment wasn’t rated yet0
Хейтер чего? Перехода на PHP7 что ли? Нет, собираюсь. Версий через 10.
Total votes 1: ↑0 and ↓1-1
Ну согласитесь, что Вы написали это не для простого информирования, ибо мы с Вами оба знаем, что переходящие на него далеко не блондинки или школота, и основательно начитаны о плюсах и минусах такого перехода, ибо это Вам не с 5.4 на 5.5 перейти. Да и тут все относительно, не помню с какой версии и на какую я переходил, но когда оператор e в регулярках оказался деперекейтед и вместо этого теперь нужно пользовать preg_replace_callback, вот это был переход через альпы!))) Почти весь проект переписали… До сих пор помню…
This comment wasn’t rated yet0
try{ } finally{} can create infinite chains of exceptions


этот баг воспроизводится в PHP 5.6.15, так что никакого отношения к семерке.

на самом деле это весьма стремный баг, но как бы он не сильно влияет на большинство людей. А с учетом того что он тянется еще с ветки 5.x я тем более не вижу проблем с переходом на семерку.
Total votes 1: ↑1 and ↓0+1
Ну так это один пример только. Для интереса гляньте сколько уже всего исправлено в 7.0.1, и это только начало!
Total votes 2: ↑0 and ↓2-2
Волков бояться в лес не ходить. Не бывает проектов без багов. В том функционале который использует 99% php разработчиков баги уже вычистили, остаются фичи или варианты использования фич которые просто редко юзаются.

В целом проблемы о которых вы толкуете выявляет толковая тест сюита проекта. Если у вас нет оной — то мне понятно ваше нежелание мигрировать на новую ветки php. Но это ваша проблема а не проблема php.

сколько уже всего исправлено в 7.0.1

7.0.1 еще нет, даже тег не выставлен. Если вы про ветку то это как бы… просто ветка. А динамика коммитов как бы не менялась, а закрывающиеся баги это замечательно.
Total votes 1: ↑1 and ↓0+1
> В целом проблемы о которых вы толкуете выявляет толковая тест сюита проекта. Если у вас нет оной — то мне понятно ваше нежелание мигрировать на новую ветки php. Но это ваша проблема а не проблема php
Мне что-то даже и сказать нечего. У вас однопользовательская однопроцессорная система на одном процессе, покрытая на 100% тестами?
> 7.0.1 еще нет, даже тег не выставлен.
И что? Я не говорю, что версия вышла, я говорю о том сколько багов сейчас в 7.0 видно по тому что правится 7.0.1.
Total votes 2: ↑0 and ↓2-2
У вас однопользовательская однопроцессорная система на одном процессе, покрытая на 100% тестами?

нет. Модель работы php (умирающая) позволяет не париться о кейсах с кучей людей одновременно ломящихся на сайт (если мы говорим о рисках связанных конкретно с миграцией версии PHP, а не разработки в целом). А 100% покрытие кода тестами не нужно, хватит и 80%. Да и без мутационных тестов ваши эти проценты покрытия как бы не сильно показательны.

Ну и я вам даже больше скажу, у меня рядом ребятки сидят, они пару недель назад переехали на php7 потому что 5.6 на их проектах после каждого запроса сегфолтился при отчистке памяти.

я говорю о том сколько багов сейчас в 7.0 видно по тому что правится 7.0.1.


если вы проследуете в ишус трекер — то большая часть багов идет еще с php 5.6. А количество коммитов на единицу времени чуть подупало после релиза, и в принципе все держится относительно стабильно. Обычный рабочий процесс.

Короче я не вижу ровным счетом никаких проблем с миграцией проектов на семерку, если в этом есть профит. А профит для большинства проектов таки есть.
Total votes 1: ↑1 and ↓0+1
нет. Модель работы php (умирающая) позволяет не париться о кейсах с кучей людей одновременно ломящихся на сайт
Тем не менее при переезде с 5.5 на 5.6 мы словили пару гонок за ресурсы в файлах.
А 100% покрытие кода тестами не нужно, хватит и 80%.
Или не хватит.
если вы проследуете в ишус трекер — то большая часть багов идет еще с php 5.6
Ок, я потом посмотрю. Тут дело не в количестве, а в серьёзности.
Ну и я вам даже больше скажу, у меня рядом ребятки сидят, они пару недель назад переехали на php7 потому что 5.6 на их проектах после каждого запроса сегфолтился при отчистке памяти.
Увы, да. Там настройки opcache надо покрутить.
Короче я не вижу ровным счетом никаких проблем с миграцией проектов на семерку, если в этом есть профит. А профит для большинства проектов таки есть.
Ну, для сайтиков — почему бы и нет?
Total votes 1: ↑0 and ↓1-1
мы словили пару гонок за ресурсы в файлах.

Какая-то уж больно экзотическая проблема. Могли бы вы рассказать? Мне на самом деле интересно.

Или не хватит.

Ну конечно все зависит от требований к проекту, его сроке жизни и т.д. Я лишь хочу сказать что честные 100% покрытие кода тестами невозможно достич как минимум потому что вам нужно будет покрыть все инварианты. И даже если код комередж показывает 100% только мутационные тесты (а под php этот вид тестирования не очень развит, хотя даже инструменты имеются) могут показать истенное положение дел.

Увы, да. Там настройки opcache надо покрутить.

Нет, к opcache это не имело никакого отношения. Это было в списке первых 10-ти вариантов того, что можно сделать. Собственно там очень специфичная бага связанная с конкретными экстеншенами сторонними, и комбинация нескольких факторов приводила к сегфолтам.

Ну, для сайтиков — почему бы и нет?

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

Я к тому что не надо агитировать людей что-то делать или чего-то не делать. Пусть сами принимают решения и взвешивают риски.
Total votes 1: ↑1 and ↓0+1
Я думаю, пора наш диалог сворачивать. Мы с вами, похоже, из разных миров.
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr