Революция PHP7: Типы возвращаемых значений и удаление артефактов

Автор оригинала: Bruno Skvorc
  • Перевод
Планируемая дата выпуска PHP7 стремительно приближается, внутренняя группа усиленно работает, пытаясь исправить наш любимый язык, сделать его как можно лучше, будут удалены артефакты прошлых версий и добавлено несколько столь желанных фич. Есть много RFC, которые можно изучить и обсудить, но в этом посте я хотел бы сосредоточиться на трех самых важных.

PHP 5.7 vs. PHP7


Как я уже говорил в прошлом письме, 5.7 был отклонен в пользу перехода непосредственно к PHP7. Это означает, что не будет новой версии между 5.6 и 7 — даже если она и появилась бы, то просто служила бы сигналом тем, кто все еще погряз в устаревшем коде. Первоначально, 5.7 не должна была иметь новые функции, но должна была выбросить уведомления и предупреждения об устаревании кода, который скоро изменится в v7.

Также необходимо предупредить о некоторых ключевых словах, которые будут зарезервированы в PHP7, чтобы люди могли быстро привести свой код в соответствие с помощью какой-нибудь «автоматической» проверки совместимости версий PHP. Однако, как я писал в рассылке, большинство людей, которые достаточно компетентны, чтобы соблюдать совместимость своего кода с последней версией PHP, на самом деле и не используют конструкции, которые может сломать PHP7.

Обратите внимание, что пока голосование неоднозначно, это говорит о том, что идея окончательно не похоронена. Участники высказываются против 5.7 из-за отсутствия значительных изменений, но с учетом новых голосов на других RFC, они вполне могут изменить свое решение. Давайте посмотрим что произойдет.

Типы возвращаемого значения (Return Types)


С подавляющим большинство голосов «за», PHP, наконец, получил типы возвращаемых значений. Результаты голосования еще свежи, но определенны. Начиная с PHP7, мы, наконец, сможем указать правильный тип возвращаемых значений функции:

function foo(): array {
    return [];
}

Улучшение? Однозначно!!! Но идеальное ли? К сожалению, нет:

  • возвращаемыми могут быть лишь те типы, которые есть на данный момент
    не будет возможности вернуть скалярные значения, такие как string, int, bool и др. Это означает, что ваши методы и функции, которые возвращают подобные значения по-прежнему останутся в исходном состоянии.
    Вы можете это исправить путем возврата экземпляров обертки для подобных значений, но это будет ненужным извращением в большинстве случаев. (прим. пер. — самое время обратить внимание на одно из предыдущих начинаний — преобразование примитивов в нормальные объекты)
  • нельзя будет определить возврат нескольких типов. Если ваша функция возвращает либо массив либо объект Iterator, то нет никакого способа указать это, например, array|Iterator как мы делаем в doc-блоках.


Некоторые люди также жаловались на объявления типа после закрывающей скобки списка аргументов, а не перед именем функции, но для меня это придирки. Популярные языки, такие как современный C++, используют “пост”-синтаксис, при этом сохраняется возможность поиска «function foo» без какой-либо необходимости прибегать к regex-модификациям. Более того, это согласуется с тем, что использует HHVM, таким образом получается непредвиденный бонус в совместимости.

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

А что думаете вы?

Удаление артефактов


Предстоящая версия предлагает удалить стилистические конструкции PHP4 (еще не голосовали). Вы можете прочитать и разобраться в этом RFC, это просто, и было бы бесполезно повторять еще раз — язык идет вперед. Мне не понятно почему такой шаг вызывает СТОЛЬКО душевных мук у некоторых людей. Например, тут: «Пожалуйста, не разрушайте наш язык», — просит Тони, который, похоже, с определенным умыслом использует удаляемый функционал.

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

Приговор «код, который я написал 10 лет назад, по-прежнему должен запускаться сегодня и должна быть возможность выполнить его через 10 лет» — для меня безумие — вы, безусловно, не должны ожидать подобного ни от одного популярного языка в рамках перехода от одной основной его версии к другой. Проведите параллель с реальным миром, вы не должны ожидать разрешения иметь рабов сегодня, только потому, что когда-то давно закон это разрешал. Да, был кровавый переход, но когда большинство сторонников рабства либо покаялись либо умерли, настал мир.

Стоит отдать должное Тони, он прав в том, что отстаивает свое мнение и прилагает большое количество усилий, чтобы его твердое «нет» было услышано. Но в долгосрочной перспективе это займет больше коллективных усилий по устранению проблем с конструкторами, чем если просто избавиться от проблемы прямо сейчас.

Понятно, сломанная совместимость всегда огорчит некоторых людей, даже если в рамках основных версий все останется нормальным, нарушать совместимость необходимо для целей прогресса. Представьте себе вой, который поднимется, когда подобные люди узнаю об этом. Блин, если бы в прошлом году не был бы обновлнен mysqli заместо mysql, то либо WordPress не смог бы корректно работать на PHP7, либо PHP7 был бы дырявым и безнадежно устаревшим по той единственной причине, что core-разработчики пожалели пользователей WP и решили оставить их счастливыми.

Мой совет тем, кто опасается PHP7 — стоп. Если вы не хотите обновляться, то и не делайте этого. Если вы сидели на 5.3 или 5.2 так долго (привет, любители CodeIgniter), то посидите на 5.6 еще десяток лет, не мешайте PHP быть современным. Оставьте прогресс для тех, кто готов принять его.

Что думаете вы по этому поводу? Вся эта затея с удалением артефактов бред или действительно нужный шаг?

В сторону: изменения Extension API


В качестве интересной заметки на полях, есть некоторые изменения в PHP7, которые могут стать причиной небольшой задержки с портированием расширений на версию 7. API для создания расширений попало под рефакторинг (чистку) и все может поменяться, тем не менее этот провакационный твит от Sara Golemon собрал немного внимания.

Damn. There are some serious surprises in the PHP7 Extension API changes. Not for nothin’, but it’s a good time to switch to HHVM.
— SaraMG (@SaraMG) January 3, 2015

Она в основном говорит о том, что изменения в создании расширений при переходе от 5.6 до 7 будет настолько большими, что проще узнать как делать расширения под HHVM. А затем она продолжает развивать тему серией статей на тему как создать HHVM extension.

Вы разрабатываете расширения? Изучали ли вы изменения и как вы относитесь к всему этому, не слишком ли рано сейчас говорить о будущем эффекте?

Edit: Мое внимание обратили на то, что Сара уже после всего этого начала документировать новое API расширений, совместимое и с HHVM и с PHP7. Похоже, можно делать расширения, совместимые с обоими рантаймами!

Вывод


Как обычно, недостатка в драме PHP-мир не испытывает. Как и во всех крупных революциях, на протяжении всей истории PHP7 также будет проливаться кровь, прежде чем произойдет что-то удивительное. PHP7 еще далек, так что даже если вы попали под перекрестный огонь мушкетных выстрелов, есть достаточно времени, чтобы добраться до выхода. Если ты спишь под гусеницей танка, то обе стороны могут мало что сделать, чтобы помочь тебе.

Что вы думаете об этих RFC? Как вы относитесь PHP7 в целом? Движется ли он в правильном направлении? Дайте нам знать — мы хотим услышать ваши мысли!
Поделиться публикацией

Похожие публикации

Комментарии 60

    0
    Если уж говорить о перспективах, так как об апи не было ничего сказано, то оное в jphp почти что идеально в той перспективе, в которой следует двигать оригинал. Яб точно не отказался увидеть это в будущей версии пыха.
      +3
      Return Types долго ждал, понравилось как было сделано в первой версии RFC, которую забраковали, исправили это поведение так:
      interface A {
          static function make(): A;
      }
      class B implements A {
          static function make(): B { // must exactly match parent; this will error
              return new B();
          }
      }
      

      Вот из-за этого поведения, return_types не будет использоваться активно. К примеру в Hack можно указать тип возвращаемого значения как 'this', то в текущей реализации в PHP этого сделать будет нельзя. В итоге люди все равно будут дальше использовать обычный phpDoc: @ return $this для этих целей, и IDE будет работать правильно.

      Если бы хотя бы добавили Генерики, было бы намного проще:
      class AbstractRepository<T> 
      {
          public function find($id): ?T
          {
              ...
          }
          ....
      }
      


      Так было бы намного удобнее это сделать (к примеру так сделано в Hack);
        +4
        Немного объяснений:
        У вас есть ваша любимая ORM'ка (к примеру Doctrine), у которой есть AbstractRepository, который используется как репозиторий по умолчанию, и также вы от него можете насследоваться. У этого AbstractRepository есть метод find, который возвращает нам объект Entity. Представим, что все Entity реализуют интерфейс EntityInterface, тогда наш AbstractRepository будет иметь вид:
        class AbstractRepository 
        {
            public function find($id): EntityInterface
            {
                ...
            }
            ....
        }
        

        Вроде все правильно, find действительно возвращает EntityInterface, но если мы будем использовать его для определенной Entity, к примеру User, мы не сможем при наследовании переопределить тип возвращаемого значения как User, то-есть такой код приведет к Fatal Error:
        class UserRepository extends AbstractRepository 
        {
            public function find($id): User
            {
                ...
            }
            ....
        }
        

        То-есть нет сужения/расширения классов, возьмем к примеру Java:
        public interface A {
            public A create();
        }
        ...
        public class HelloWorld implements A
        {
             public static void main(String []args){
                HelloWorld a = new HelloWorld();
                a.create();
             }
             
             public HelloWorld create() {
                 return this;
             }
        }
        

        Такой код является валидным, так как он не противоречит условию.
          0
          В вашем примере есть еще одна проблема — make всегда должен возвращать B. То есть тот же пример с find у абстрактного репозитория с
          nullable types в draft-е лежит уже, без него смысла лепить это дело на методы типа find сами понимаете мало. В целом же пример с абстрактным репозиториями я лично считаю надуманным.
            0
            Имхо — подобный драфт не совсем практичный, намного удобнее было бы унифицировать аргументы для получения нескольких значений, например вот таким образом:
            public function some(SplFixedArray|null $any) 
            {
            }
            

            Это позволит не только определять аргумент, как nullable, но и указывать несколько типов аргументов. Хотя вариант с перегрузкой был бы всё же красивее…
              +1
              ну во первых подобный синтаксис есть и в java и в c# и используется оно по прямому назначению, разрешает использование null как значение. ваш вариант кроме того что выглядит ужасно, так ещё и убивает весь смысл тайпхинтинга. Если ваши методы/функции работают с разными типами то и тайпхинтинг вам не нужен.
                0
                Так реализовано в TypeScript — по-моему это лучший вариант при наличии типизации в аргументах, но отсутствия перегрузки. Хотя с другой стороны может вы и правы и вполне достаточно хинтинга в автодоках для подсветки и разруливания типов в иде.
                0
                не имеет смысла при крайней нестрогой типизации php, имхо…
                  0
                  Я бы сказал не «крайне нестрогой», а «опциональной». Т.к. при желании можно писать почти так же, как на джаве (используя строгие spl-типы, например).
                    0
                    Кстати на счёт «крайней нестрогости». Вот такое будет работать везде:
                    Пример (Чур в обморок не падать)
                    <?php
                    $i = int(23.0);
                    $f = float("asdasdasd");
                     
                    class Test
                    {
                        public static function printInt(int $i)
                        {
                            echo $i . "\n";
                        }
                     
                        public static function printFloat(float $i)
                        {
                            echo $i . "\n";
                        }
                    }
                     
                     
                    Test::printInt($i); // 23
                    Test::printFloat($f); // 0.0
                    

                    А вот реализация
                    <?php
                    abstract class number
                    {
                        protected $value;
                        public function __construct($val)
                        {
                            $this->value = $val;
                        }
                     
                        public function __toString() { return (string)$this->value; }
                    }
                     
                    class int extends number
                    {
                        public function __construct($v) { parent::__construct((int)$v); }
                    }
                    class float extends number
                    {
                        public function __construct($v) { parent::__construct((float)$v); }
                    }
                     
                    function int($v) { return new int($v); }
                     
                    function float($v) { return new float($v); }
                    

                      0
                      Все бы было круто, если бы

                      echo $i + $f;
                      


                      или
                      if ($f)
                      {
                      	echo $f;
                      }
                      


                      после этого работало) А так бесполезно…
                        0
                        не спорю, осталось дождаться ассепта вот этого: wiki.php.net/rfc/object_cast_to_types =)
                          0
                          Скорее эту примут, чем драфт 3-х летней давности.
                            0
                            По-моему эти rfc несколько разной направленности.

                            По моей ссылке позволяет нормально приводить объекты к другим типам, как следствие:
                            1) позволяет обходить такие проверки, как is_array при реализации объекта с интерфейсами ArrayAccess и проч.
                            2) позволяет выполнять математические операции, какое-нибудь сложение специфичных объектов, например векторов (Vector2), хотя с этим придётся помучаться, т.к. получение слагаемых вроде бы не предусмотрено
                            3) и уже в последний момент для подобной откровенной издёвки над языком, как я привёл выше, в качестве реализации строгой типизации

                            По вашей же ссылке — вполне очевидный рфц, добавляющий типы для скаляров (за исключением массива, т.к. он уже есть) и предназначенный только для этого. Т.е. перспектива очевидна и «унитарна», если так можно выразиться.
                              0
                              По моей ссылке, вменяемый свежий RFC решающий конкретные проблемы. Возможность же каста объектов в скаляры штука весьма неудобная и создает почву для говнокода. Все эти эмуляции перегрузки операторов вообще не нужны ни разу. Эмулировать что-то таким способом тоже не очень то удобно и уж темболее я не хочу увидеть такой код (ваш пример с реализацией тайпхинтинга для скаляров на базе этой штуки) у себя в продакшене.
                0
                > В вашем примере есть еще одна проблема — make всегда должен возвращать B.

                Это не проблема, особенно если вспомнить что type hinting в такой ситуации прекрасно умеет проверять цепочку наследования и выбрасывать E_RECOVERABLE_ERROR.
                  0
                  я про то что метод find может вернуть null, а в текущем варианте при использовании тайпхинтинга — не может. Потому пример предложенный на java в php пока реализовать не удастся.
                0
                Аббревиатура LSP вам о чем-нибудь говорит?
                  +1
                  Постусловия не могут быть ослаблены в подклассе.

                  Вроде всё пучком. В приведённых примерах постусловие усиливается.
                    0
                    Если всегда в возвращаемом значении ожидается instanceof A, то все пучком, но тогда и нет смысла в таком переопределении.
                      0
                      Аббревиатура LSP вам о чем-нибудь говорит?

                      Тогда я не понял что Вы имели в виду, можете пояснить?
                +2
                Это означает, что ваши методы и функции, которые возвращают подобные значения по-прежнему останутся в исходном состоянии.
                Вы можете это исправить это путем возврата экземпляров обертки для подобных значений, но это будет ненужным извращением в большинстве случаев.

                ИМХО, проблема скалярных типов не в возвращаемом значении, а в отсутствии методов

                __toBool
                __toInt
                __toFloat

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

                $a = new Bool;
                if ($a)


                Приговор «код, который я написал 10 лет назад, по-прежнему должен запускаться сегодня и должна быть возможность выполнить его через 10 лет»

                Вроде за 10 лет была куча изменений, которые ломали обратную совместимость — хотя бы, выводили NOTICE или WARNING, что уже половину сайтов делало не работоспособными.

                  +1
                  github.com/php/php-src/pull/998 — я расчитываю на то что в 7.0 это дело все же войдет.
                    0
                    Может вы знаете, есть какой-нибудь простой способ собрать php с этим делом?
                      0
                      Да, перейти на Hack. Ну а так — собрать так же как и сам php. configure && make.
                      0
                      Вариант Nikic, с преобразованием примитивов в полноценные объекты, мне больше нравится. Такм образом можно будет убрать бардак с именнами и аргументами стандартных функций в PHP, и как бонус заработает TypeHinting для «примитивов».
                        0
                        А еще это добавит изрядно оверхэда ибо вместо хранения одного жалкого int у нас в памяти будет жирная структура. А там и накладные расходы и т.д. Либо же надо изрядно переделывать парсер что бы тот трансформировал это добро в нормальные конструкции.

                        Имхо превращать все в объекты это не сильно практично. Ну и проблемы тайпхинтинга для содержимого массивов это никак не решает. Как по мне так уж лучше на Hack перейти за всем этим добром.
                          0
                          — int, string и т.д. как примитивы явно останутся, ибо совместимость.
                          — phpng уменьшит размеры структур.
                          — другой альтернативы исправить php api, я не вижу.
                          — type hinting заработает бонусом.

                          С массивами сложнее… в php вообще с колекциями плохо, даже в spl.

                          А к Hack я уже давно присматриваюсь. Останавливает только отсутствие поддержки нативных php расширений, а переписывать не хочется.
                            0
                            Можете первый пункт раскрыть? Если я правильно понимаю, в этом случае нужно править синтаксис языка, причем не слабо.

                            В интерналс сейчас идет обсуждение единого API для расширений под HHVM и PHP. Правда думаю долго еще ждать и не факт что что-то такое вообще будет. Я стараюсь реже использовать какие-то кастомные расширения как раз таки для того что бы код был максимально переносим.

                              0
                              другой альтернативы исправить php api, я не вижу.


                              Предлагаю всё же попробовать заглянуть на светлую сторону jphp ;) Ну например: github.com/jphp-compiler/jphp/blob/master/jphp-runtime/src/main/resources/JPHP-INF/sdk/php/lib/str.php
                      +3
                      > не будет возможности вернуть скалярные значения, такие как string, int, bool и др.

                      Учитывая что они свободно конвертируются друг в друга это не особо печально.

                      > нельзя будет определить возврат нескольких типов.

                      Есть языки где это возможно?

                      > Некоторые люди также жаловались на объявления типа после закрывающей скобки списка аргументов, а не перед именем функции, но для меня это придирки. Популярные языки, такие как современный C++, используют “пост”-синтаксис, при этом сохраняется возможность поиска «function foo» без какой-либо необходимости прибегать к regex-модификациям.

                      Несколько странно видеть сравнение с с++, разве java/c# не ближе? «Поиск» вообще не актуален, IDE давным-давно решили данную проблему. ИМХО, префиксная запись гораздо читабельнее, особенно при большом количестве аргументов.

                      > Понятно, сломанная совместимость всегда огорчит некоторых людей

                      Тони похоже просто говнокодер, конструкторы совпадающие с именем класса во всех книгах/статьях не рекомендованы к использованию еще со времен перехода с 4.0 на 5.0, поэтому в нормальном коде эта проблема не может существовать в принципе. Буду рад если выпилят (большая часть остального тоже давным давным устарела).

                      > Как вы относитесь PHP7 в целом?

                      Раз уз добавляют указание возвращаемого типа, то пусть и properties сразу добавят (возня с магией уже порядком надоела) и перегрузку методов до кучи (вот это будет по настоящему круто).
                        –2
                        > нельзя будет определить возврат нескольких типов.

                        Есть языки где это возможно?

                        Swift?

                        func minMax(array: [Int]) -> (min: Int, max: Int) {
                            var currentMin = array[0]
                            var currentMax = array[0]
                            for value in array[1..<array.count] {
                                if value < currentMin {
                                    currentMin = value
                                } else if value > currentMax {
                                    currentMax = value
                                }
                            }
                            return (currentMin, currentMax)
                        }
                        
                          +5
                          А это разве не кортеж? (структура/массив)
                            0
                            возврат нескольких переменнных это другое.
                            0
                            >Учитывая что они свободно конвертируются друг в друга это не особо печально.

                            Какая вообще связь?

                            >Есть языки где это возможно?

                            В PHP есть возможность возвращать значение разных типов, но указать этого нельзя.
                              0
                              Оно не особо нужно из-за конвертации: сейчас по сути все равно что возвращает метод 0, false, null или еще что-то приводящееся к false. Если же вам это критично всегда можно явно привести тип. Да и опять же — скалярного type hinting все равно нету, добавлять так все вместе.
                                0
                                Ну, если мы идём по пути увеличения строгости, то уже должно быть важно, 0 или NULL.
                                  0
                                  в текущей RFC тайпхинтинга для скаляров всеравно нету ничего для проверки содержимого массивов… грусть печаль.
                                0
                                Есть языки где это возможно?

                                Typescript же!
                                +1
                                Долго не мог понять это место «возвращаемыми могут быть лишь те типы, которые есть на данный момент» и почему это типов int и bool на данный момент нету.
                                ИМХО надо пояснение, что речь идет о типах, которые можно было использовать в type hinting аргументов ф-ий.
                                  0
                                  Еще есть интересный rfc про дефолтные конструкторы для объектов. Вещь далеко не критичная, но удобная например при написании юнит тестов. Увы проголосовали 50/50, но так как это изменение на уровне языка, то требуется 2/3+1 голос для принятия.
                                    0
                                    А можете пояснить, в чем удобство для написания юнит тестов?
                                      0
                                      В моей практике постоянно нужно следить существует или нет конструктор создаваемого объекта, чтобы его замокать. Но не удивлюсь, что в phpunit это уже давно решили какой-нибудь проверкой на существование конструктора (буду честен — не проверял).
                                      Также есть удобство в написании конструкторов дочерних классов (это был кстати основной аргумент автора rfc), когда можно было бы всегда смело писать parent::__construct() независимо от того, есть он или нет.
                                    –1
                                    Целиком и полностью за избавление от пережитков PHP4 — лучше переделать свое приложение, чем опять тащить кучу ненужного барахла в новую версию. Насчет типизации возвращаемых функцией значений. ИМХО зачем делать еще одну Java или Ruby? Или с этой фичей говнокод сразу станет конфеткой? Выбросить балласт — очень правильное решение. Наворачивать избыточный функционал — ИМХО нет.
                                      0
                                      Почему вы считаете что этот функционал избыточен? В любом случае право использовать тайпхинтинг или нет — ваше право.
                                        +2
                                        Насчет типизации возвращаемых функцией значений. ИМХО зачем делать еще одну Java или Ruby?

                                        Ruby? Вы уверены? Никогда не видел в Ruby type hinting, тем более возвращаемых значений.
                                        –4
                                        Тони в «Не ломайте наш язык» прав в том смысле, что большинство core девелоперов не имеют достаточного опыта (и популярный Никита Попов — туда же). Тенденция в PHP — ломать работающее — не может не настораживать. Не вижу ничего плохого в том, что сам язык обратно совместим с собой же. По своему небольшому хостингу (~50 клиентов) могу сказать, что замены версий PHP и без намеренного слома очень болезненны (то, что задело — HTTP_xxx_VARS, ereg_xxx). После окончательного слома конструкторов может навернуться масса легаси софта (в т.ч. и покупного).

                                        Еще «замечательно» то, что команда, ломая совместимость, абсолютно плюёт на разработчиков. Так, не припомню ни одного анализатора кода на выявление в коде отломанной функциональности. Стоило бы вменять в обязанности делать такие анализаторы тем, кто голосует за удаление — при принятии такого решения.

                                        Обратная совместимость — это огромная сила. И все исторические примеры это только подтверждают (тот же Python 2/3 — который приходится держать обе версии, Windows 8). И где был бы сейчас C++, если бы не его совместимость с C? Думаю, там же, где и всякие PL/I, COBOL, etc — на свалке истории.
                                          +2
                                          Может быть объясните, но я не понимаю зачем заставлять древний код работать под новым интерпретатором? А вообще советую посмотреть на C#, один из наиболее быстро и часто обновляющихся языков, и никто не ноет.
                                            +1
                                            Объясняю — команда позиционирует его как замену текущей ветки 5.x. Соответственно поддерживать 5.х бросят, а сам интерпретатор _очень_ дырявый с точки зрения безопасности. Соответственно минимум хостинги встают перед дилеммой — обеспечивать безопасность или сохранять совместимость.

                                            По своим клиентам — у меня есть код, написанный более 14 лет назад (для интерпретатора 4.0). И он до сих пор работает. Я не вижу ни единой причины, чтобы перетряхивать его бесплатно. С точки зрения клиентов доп.затраты на его обновления — аналогично, бессмысленны. Так что команда PHP такими жестами перекладывает свою работу на разработчиков.

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

                                            Никто, собственно, не ноет, проблем нет уйти в новых разработках на что-то более стабильно относящееся к обратной совместимости. И с потерей «старой гвардии» язык рискует просто уйти в тень — как то потихоньку происходит с Perl (крайне неудачная история развития). С python слабо знаком — но подозреваю, популярность они себе сами подорвали выкрутасом с миграцией 2.х -> 3.x

                                            Насчет C# — там действительно всё так же печально с обратной совместимостью? Насколько я могу видеть, .NET 2 вышла в 2005, конец поддержки Microsoft обещает на 2016 год. Немного расходится с поддержкой PHP, правда?
                                              0
                                              Статью попозже постараюсь почитать, но выход вы вовсе не там ищите — не нужно всех заставлять пользоваться старыми кривыми костылями, поддержка которых к тому же тормозит эволюционное развитие (приходится тратить время на обновление этого кода). Вместо этого, как вы сами сказали, нужна версия с длительной поддержкой в которой будут фиксы безопасности (или что-то совсем критичное). Поэтому просить стоит именно об этом, а не о мифической обратной совместимости.
                                                0
                                                В рамках текущей модели развития языка это (поддерживание старых фич) единственное, что можно сделать. Безусловно, если был бы вариант перейти на LTS — по меньшей мере виртуальные хостинги так бы и сделали.

                                                И (сейчас меня заминусят) вот я чего чисто психологически не понимаю — вроде ж все не дети, а у многих (и в команде PHP, и здесь) кипит типичный юношеский максимализм в обсуждении «старое vs новое». Новая версия — значит всё резать! И (сугубое imho) комплексы неполноценности языка — когда в язык некритично тащат всё подряд.

                                                В плане совместимости мне очень нравится здравый консерватизм FreeBSD, когда поверх базы создаются слои совместимости (и их можно как включить, так и выключить). В PHP почему-то старые возможности необратимо режутся. С расширением ereg например нехорошо получилось — вполне можно было его убрать из базы в PECL (как например сделали для dbase). Мой код например именно его использовал (т.к. в 2000-2001 в документации писалось, что preg тормознее).

                                                Подытоживая, пока у текущей команды PHP такой настрой, как мне кажется, ни о какой LTS ветке речи быть не может. И статья Тони (отражающая мнение части PHP-пользователей) — глас вопиющего в пустыне. Сложность саппорта LTS выше, чем саппорта в текущем коде отдельных «устаревших фич».
                                                  0
                                                  LTS оказывается как бы есть, но не бесплатно: www.zend.com/en/support-center/support/php-long-term-support
                                                    0
                                                    Спасибо за информацию, не знал. Оно в комплекте Zend Server, цены только не радуют — shop.zend.com/en/production-solutions.html (хотят $185 в месяц за минимальный Small Business).
                                                      0
                                                      Либо 2200 в год либо намного больше на миграцию кода. Как по мне если речь идет о проекте, который использует код 10+ летней давности и переписывать его дорого, вполне приемлемая цена.

                                                      Можно постараться интегрировать возможности предоставляемые платформой и тогда будет не только LTS но еще и плюшки.
                                                        0
                                                        Я думаю, вопрос приемлемости цены — это не тот вопрос, который решает разработчик/сисадмин? Для небольшого хостинга например ценник неподъемный.
                                                          +1
                                                          А причем тут небольшие хостинги? Это не их проблема. Это проблема разработчика/клиента, которому можно предоставить VPS а Zend Server пусть он покупает.

                                                          Я вообще вот честно слабо представляю себе системы написанные на PHP4, которые проблемно перевести на PHP5.6. Только в случаях использования каких-то специфичных экстеншенов.
                                                +5
                                                Всё верно. Все фичи пятерки должны жить.
                                                Но речь идет про функционал четверки. Если вы не хотите переносить код с четверки на семерку, то… не переносите. Пользуйтесь четверкой.
                                                Не хотите пользоваться четверкой? Почему вы считаете что разработчики пхп должны поддерживать ДАВНО устаревший функционал? Вам сложно написать десять строчек кода, чтобы пройтись по своему коду в поисках устаревшего кода?
                                                Очень логично было, что этот функционал был сохранен в 5.1. Логичен он был и в 5.2.
                                                Но лично я был сильно удивлен сегодня, прочитав что он еще живой. Я думал, что он умер уже в 5.3.

                                                И да, я чрезмерный консерватор. И да, у меня есть некоторый код, который после небольшого рефакторинга перешел из Бейсика в Паскаль, а потом в пхп4, и сейчас живет в пхп5.4., и да, я вот прямо сейчас испытываю небольшие трудности с переносом старого фреймворка с 5.1 на 5.4. (обидно, что это происходит в рамках плавного отказа от того фреймворка и переноса на другой). Но сохранять такие мелочи как конструктор с именем класса… Увольте.

                                                ПостСкриптум: Еще хотелось бы услышать реальных примеров того как такой код вообще мог дожить до времен 5.4… В четверке классы были очень проблемными, и пользовались ими мало. После этого было много серьезных изменений которые требовали хоть какого-то рефакторинга. Нет, я сам разгильдяй, и очень часто игнорирую нотисы с депрекейтами. Но не до такой же степени…
                                                ПостПостСкриптум: Если кого-то обидел, то простите, я случайно. Жена рожает, я немного нервный :) Так что резкость оборотов делите на два)
                                                  +1
                                                  Речь не об этом. У меня есть большое купленное приложение на PHP 4, благополучно функционирует на 4.4.9 (внутри ВМ), меня это устраивает. Клиент (муниципальное учреждение) не может себе позволить купить апгрейд за 40т.р. и потратить неизвестный объем времени/денег на перенос данных.

                                                  Из встреченных примеров — сайт другого муниципального учреждения, сделанный в 2011 году (по гос. конкурсу за бешеные деньги), внутри объектный, конструкторы все «старые». По инспекции кода — база CMS писалась человеком в 2001-2002 году, сам автор успешно отчалил в штаты, веб-студия до тех пор (минимум до 11 года) использовала старые наработки (ну работает же — не трожь). Собственно, сайт (а он там не такой) будет держать виртуальный хостинг на 5.х еще много времени. Собственно, вот — плач Ярославны месячной давности, прямой результат политики команды PHP.

                                                  Речь собственно о стратегии (отсутствующей) развития языка. Когда базовая функциональность может внезапно быть объявленной устаревшей и выкинута. Речь о правилах и принципах, которые обязаны соблюдать даже лидеры проекта.

                                                  В любом проекте накапливается рутина, которую всё равно надо делать. Обеспечение обратной совместимости, поддержка кода — это да, ни разу не фан. Но это нужно делать, это нужно финансировать (временем разработчиков и/или деньгами). Иначе большой продукт не будет отличаться от студенческой поделки ничем.

                                                  Мне тоже очень нравятся новинки языка (не все), и здорово, что оно обновляется и расширяется. Но как системный администратор, я не могу рисковать сайтами клиентов — в том числе и из-за логов изменений языка. И из-за этого сайты, требующие 5.4 и выше — вынуждены покупать более дорогие виртуалки, хотя в остальном нужды в них нет.
                                                    +2
                                                    Проблематика понятна — нет денег чтобы сделать как положено, поэтому пусть за них потратят деньги другие люди, или «в тендере выиграли люди которые использовали депрекейтет функционал даже когда он был уже депрекейтет — разработчики языка за них в ответе!».
                                                    Я их прекрасно понимаю. У самого есть такие ситуации/клиенты. Но!
                                                    Есть общепринятая практика — обратная совместимость сохраняется в рамках последней цифры, частично сохраняется в рамках средней цифры и не сохраняется в рамках первой.
                                                    Если бы эти конструкторы выкинули в 5.2, то я бы вас понял. А так… Давайте еще требовать совместимости с пхп3, ведь у кого-то еще может есть код времен пхп3?
                                                  0
                                                  Если ваш код под 4.0 работает на 5.4+ без правок, видимо, там вообще чистая процедурщина, иначе бы одни амперсанды в аргументах замучались удалять (именно по этой причине у меня, кстати, крутится 5.3 на сервере со старьем). А с процедурщиной вроде бы ничего и не ломают сильно: ереги просто выносятся в pecl-расширение, а уж HTTP_VARS вообще не проблема — добавить три строчки в auto_prepend_file да и всё.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое