Pull to refresh

Comments 41

Оо… далеко не первый год в PHP, но не знал про наследование интерфейсов. Всмысле, вообще не задумывался, что в интерфейсе можно делать extends :) Как-то не встречалось и не пригодилось. Отложу в копилку супер-нужных знаний, вдруг понадобится.

Кстати, указывайте о какой версии PHP идет речь. А то начнут указывать тип int в аргументах метода ниже 7-й версии и сильно удивятся.
Спасибо, что обратили внимание. Везде, где не указано обратное, речь идет об актуальной стабильной версии PHP. В данный момент это, как известно, PHP 7.1

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

И на курсах такой же принцип.
Просто в мире PHP «последняя» и «актуальная» версия, к сожалению сильно отличаются.

Я сейчас не так активно работаю с клиентскими серверами, но еще ни разу не встречал стороннего сервера с 7-й веткой. Только если ставили специально, а это, увы, не всегда возможно. У самого большой проект на дебиане под который просто нет 7-й версии, приходится жить на 5.6 :(

P.S. Я знаю про некую статистику по которой бОльшая часть серверов на 7-й версии. В реальном мире статистика не работает, к сожалению.
Мы с вами живем в каких-то разных «реальных мирах».

Я тоже разработчик, активно практикующий (в том числе на основной работе). Встретить где-то PHP 5 для меня — это как увидеть на улице динозавра. Теоретически возможно, конечно, но на практике не встречается :)

Позвольте полюбопытствовать, зачем вы так? Какие скрытые фобии перед PHP 7 вами движут?
Не не, вы не так поняли :)
Я лично — всецело за новые версии, тем более когда они привносят столько полезного.

Может быть я такой, но реально не встречал «обычных» проектов, созданных еще во времена 5-й ветки, которые бы сознательно обновлялись до 7-й. Они просто работают… и все тут :)

«Обычных» — имею ввиду блоги, небольшие магазины и пр. проекты до 10к/сутки.
Так а что мешает-то?
$ sudo apt update
и вуаля — вы на заветной «семерке».

Если раньше у вас не было классов, которые назывались Int или String, никаких проблем не будет. Всё просто будет работать, как и раньше, просто в 3 раза быстрее и в 2 раза экономнее по памяти.

Если такие классы были — переименуйте. Дел на 10 минут.
Ну ОК, поднять тестовый стенд клонированием боевого, дать ему другой домен и прогнать все приемочные тесты. 20 минут, хорошо.

Или я чего-то не понимаю?
Для начала — любое обновление требует проверки работоспособности и, возможно, некоторых исправлений. Согласен, 7-я ветка относительно совместима с предыдущей, но все же. Я не раз обновлял версии PHP и думаю вы тоже, так что должны знать, что бывают такие внезпные казусы, что проще оставить как есть.

Затраты времени должны кем-то оплачиваться. По крайней мере я ценю свое время и усилия и обновлять бесплатно мало кого буду. А зачем клиенту платить за кота в мешке? У него и так VDS за абстрактную 1000 руб./мес простаивает.

Собственно, это основная причина по которой «простые» проекты могут оставаться на 5-й версии очень долго. Пока обновление сильно не понадобится — оно никого не волнует.

Второй момент: обновление не всегда возможно. Например, около года назад я хотел так же обновить PHP 5.6 > 7 на Debian 7 на собственном проекте. Но оказалось, что под эту ОС его просто нет. Возможны танцы с бубнами, вроде как, но зачем оно мне? Обновление не критично, производительности мне с головой хватает. Можно обновить ОС и потом обновить PHP, но, снова, а зачем мне эти проблемы?

Третий момент вам описали ниже: если вы думаете, что класс Int и String — это все, что может помешать обновиться, то перечитайте еще раз вот эту страницу: http://php.net/manual/ru/migration70.incompatible.php

Я как-то обновлял PHP 5.3 > 5.4 (казалось бы) на одном сервере веб-студии с кучей-кучей мелких проектов. И это был такой ад, что в итоге мы просто вернули все обратно. Иногда обновление просто нецелесообразно.

Ну и, да, не стоит делать просто update, лучше все же осмысленно обновлять пакеты поочереди, если хочется обновить все и сразу. Вдруг что-то полетит и ищи потом причину.

P.S. Кто придумал эту глупость с ограничением комментов на 1 в час? Ну высказал свое мнение, нахватал минусов — теперь не напишешь ничего толком (
перечитайте еще раз вот эту страницу: http://php.net/manual/ru/migration70.incompatible.php

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

Повторю свой вопрос: ну что я делаю не так? В чем ошибаюсь? Чего не знаю еще о PHP, что знаете вы? Расскажите, интересно же!

UPD Плюсанул вам в карму, может поможет :) Но пожалуйста больше никогда не ставьте реф-ссылки…
При большом легаси в несколько MLOC потребовалось значительное время на перевод. Сначала сделаны были git hooks с запретом на коммиты кода с несовместимыми с php7 конструкциями — иначе переводить проект, где код пишут сотни php программистов не представлялось возможным. После последовательный перевод кода на 7. Не скажу что много работы, но и не мало получилось. Определенную сложность доставили расширения, поменявшие свою версию — привалило работы для qa на тестирования функционала, связанного с этими расширениями. И баги находились.
В целом для большого проекта получился быстрый переход. Но конечно не человекодни.
Переход на php 7 в зависимости от проекта требует разных усилий.
На моей памяти летом прошлого года был случай когда переходили с 5.4 на 5.6 чтобы развернуть докер и с него перейти на 7ку. Весь код проверили и привели к совместимости. Но на тестах бились юзеры один раз запускаешь и потом все не работает. Ушло примерно 2 недели осмысления в фоновом режиме на то чтобы понять, что используемая библиотека шифрования в новой версии работает иначе и оттуда проблемы. ПРишлось пробегаться по всем юзерам и пересчитывать перед обновлением. Так что увы не все так однозначно.
Никто с вами не спорит, что усилия нужны.
Просто я считаю, что многие комментаторы тут преувеличивают «масштаб бедствия».
Согласен, но хорошо бы уточнить, какого размера в строках кода были те проекты, где перевод занял человеко-дни и участвовали ли QA в переводе проектов, или было большое покрытие тестами, или помолясь…
Размер: скорее 10 в пятой, чем в шестой
Без QA я не работаю уже много лет, поэтому ответ «да, конечно же». Как вообще можно деплоить без регресса?
Одна некогда популярная CMS ещё писаная в эпоху 4-го пхп, затем переведённая на 5.2 после чего так она лет 10 работала.
Года 2 назад решили перевести её на 7-ку, 200К строк кода, 2 недели неспешной работы и вполне себе запустилось на 7.1, а с 7.1, далее переходы на 7.2, 7.3, 7.4 занимали пару менее дня (да и то затраты были на тестирование, а не на переписывание кода).
Основные проблемы (даже не проблемы, а то что пришлось переписывать) при перехода на 7.1 были: указатели, и конструкторы классов.
Немного некорректно покупать следующую модель телефона, когда тебе хватает и текущей. Должна быть прямая цель или необходимость. Обновление просто ради обновления.
Мы не про телефоны говорим, это какая-то ложная аналогия.

Стоимость нового телефона обычно не меньше, чем цена старого, в случае же обновления версии PHP нет никакой необходимости заново переписывать всё приложение.
$ sudo apt update
и вуаля — вы на заветной «семерке».

… иии, опс, ломается расширение MySQL (mysql_connect() ), которого в 7+ разумеется просто нет (и правильно).

А на нём весь небольшой магазин работал…

и ведь работал же?! Зачем сломали? Почему магазин не работает! Слыш, чувак, я клиентов теряю!
Если раньше у вас не было классов, которые назывались Int или String, никаких проблем не будет. Всё просто будет работать, как и раньше, просто в 3 раза быстрее и в 2 раза экономнее по памяти.

Если такие классы были — переименуйте. Дел на 10 минут.


Не на 10 минут.
Если работа с базой через классы организовывалась, то достаточно просто было подправить в методах класса mysql_ на mysqli_

Спасибо, кэп. А если нет?


В моей практике PHP-реаниматолога разные случаи были… и "собственный драйвер доступа к БД" встречается в примерно 10% случаев.

Тогда автозаменой по всему проекту.
Благо что формат функций mysql_ и mysqli_ за каким-то малым исключением полностью совпадает.
Есть проекты, живущие 5, 6, 7, 10(!) лет. В них просто тонна кода, адаптация под php7 требует ресурсов, которых всегда не хватает. Планы по пееходу конечно есть, но это сложно. т.к. ресурсы, время, деньги… Просто так сказать заказчикам по всей России, что нужно перейти на новую версию не поможет)
Ну пусть живет 10 лет. Это же прекрасно!

Вы в этом проекте деньги получаете от заказчика за поддержку? Включите в план поддержки обновление софта на сервере. Не получаете денег? Ну тогда нет и вопроса для обсуждения.

Не считайте бизнес идиотами — они всё понимают не хуже вас. И что такое «почти бесплатно поднять производительность в 3 раза, просто один раз пройдясь по списку из трех возможных несовместимостей» тоже поймут.

Мне было бы стыдно получать деньги за проект, на котором я впариваю заказчику PHP 5.6, честное слово. Это пахнет каким-то обманом: «чувак, ты нам платишь, но мы тебе впариваем за твои же деньги устаревшее фуфло и скрываем от тебя информацию о том, что можно обновиться».

P.S. Если речь не идет о товарно-денежных отношениях — возможно всё. Свой домашний проект можете хоть на PHP 3 ради интереса поддерживать.

P.P.S.
Если вы так уверены в своей точке зрения — предлагаю пари. С вас репозиторий проекта, который вы считаете сложным для перехода и сценарий его развертывания (или образ какой-нибудь виртуалки, мне всё равно). С меня честный отчет и хронометраж времени, которое я затрачу на «адаптацию» кода. С отчетом потом можете делать что угодно, в том числе использовать, как план для обновления.
Если вы так уверены в своей точке зрения — предлагаю пари.

А пари в итоге было принято?
У самого большой проект на дебиане под который просто нет 7-й версии, приходится жить на 5.6 :(

То есть про backports & dotdeb он не знает, да?
Выше уже несколкьо раз сказали, что обновить можно все, но зачем? Обновление ради обновления не делается.
Вас уже давно все услышали. А вот вы противоположную точку зрения — не хотите слышать.

Обновление делается не ради обновления, а ради того, чтобы затратив усилия на X рублей, получить от этого преимуществ на Y рублей. Желательно, чтобы Y >> X

Переход на PHP 7 обычно соответствует этому условию.
То есть прирост производительности в 30%-70% лишний да?
Вот реально 7 работает быстрее на том же железе чем 5.6. Если код был написан нормально, без совсем уж устаревших вещей (ну к примеру, написанный под свежие на момент выхода 5.3 вещи), то он переносится под 7 практически без проблем.
Более того, сейчас переносим проект, который все еще работает на 5.3, но с пачкой устаревшего кода, времен чуть ли не php 4. Да, приходится старые куски со спагетти кодом заменять новыми, но их не так уж много (в основном это всякие крон задачки), но оно стоит того. Остальное в PHP7 заводится к удивлению даже лучше, чем если бы мы перетаскивали его на 5.6.
В итоге то, что работало на 8-ми хардверных ядрах с LA 2-3, работает в виртуалке с одним ядром с LA 0.3
Однажды опубликованные статьи имеют свойство жить годами. За это время версии систем будут меняться. Так что указывать версию, по которой написана статья очень желательно.
Имеется костыль на PHP 5.6 (через переопределение обработчика ошибок), чтобы заставить типизацию работать и там.
Интерфейс, если не брать множественное наследование, фактически по смыслу близнец абстрактного класса без защищенных и приватных элементов.

Имхо соединение интерфейсов в один усложняет понимание кода и повышает связность. Полагаю, самый лучший вариант — перечислять все после implements, а сами интерфейсы распилить на максимально независимые сущности.

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

Интерфейс должен скрупулезно совпадать с реализацией


Понимаете, тут такое дело: или вы знаете язык, за знание которого вам собираются платить деньги, или нет. Если нет — собеседование не пройдено. Если да — имеете право на своё мнение.

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

И это не «лазейки». Это так устроен PHP. Как бы вам это не нравилось :)
Обычно я нанимаю людей. Знание языка вообще ничего не гарантирует. Более того, в реальной работе чем меньше малоизвестных «особенностей», тем надежнее проект. Платить есть смысл за реализацию задач, а не знание языка. Более того, если у чела есть ряд качеств, на пробелы в знании языка можно закрыть глаза.
Давно заметил, что тесты проходят, если реализация интерфейса добавляет дефолтное значение. Но я ругаюсь на такое

И зря — интерфейс это декларация соглашения о вызовах, поэтому под интерфейс может подпадать любой метод который может быть вызван как написано в интерфейсе
Если в нескольких местах у вас требуется именно implements A,B,C то следует его объединить в один интерфейс, т.к. будет момент когда вам захочется написать function foo(A+B+C $var)
Заодно это сразу подскажет что в данном месте это именно связанные реализации
Возможность пропихнуть «прицеп» из необязательных параметров в любой интерфейс вообще обнуляет ценность интерфейса. Смотришь на красивую декларацию, а там на самом деле скрытые зависимости. Это недочет в дизайне движка, чтобы сохранить совместимость с пятой версией. Можно сгладить недочеты языка, если ограничивать себя и следовать строгим принципам кодописания.

В контексте собеседования — это вообще запредельное буквоедство. Если чел педант и любит строгое соответствие декларациям, но не знает, что есть совместимость методов? Экзамен в универе может и не пройдет, но для работы очень даже привлекательный персонаж.
Откуда скрытые зависимости? Это же не обязательные параметры, любой вызов метода из интерфейса будет гарантированно вызван.
Совместимость с РНР5 тут вообще не причём, это утиная типизация и такой подход не только в РНР

Ну ок, например есть интерфейс отрисовки "фигур", некий упрощенный кусок проекта с планировками зданий:


interface DrawShapesInterface {

    public function drawCircle(int $x, int $y);
    // ... прочие фигуры аналогично
}

Потом некий умник делает следующее, ведь PHP позволяет:


class SimpleDrawer implements DrawShapesInterface {

    public function drawCircle(int $x, int $y, ...$args)
    {
       // отрисовка, которая зависит от дополнительных аргументов:
       // кисти, параметры цвета и т.п.
       // ведь так просто подсунуть в интерфейс еще и прицеп    
    }
}

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

Sign up to leave a comment.

Articles