Возможное будущее для PHP

http://karlitschek.de/2014/10/a-possible-future-for-php/
  • Перевод

Изображение взято с wikimediafoundation.org

От переводчика: данный пост является вольным переводом статьи A possible future for PHP, написанной Frank Karlitschek, основателем компании ownCloud и разработчиком одноименного открытого продукта для создания облачных хранилищ .


Если посмотреть на последние статистические данные OwnCloud является одним из крупнейших проектов с открытым исходным кодом, написанным на PHP. Большинство из вас знает, что PHP используется для реализации серверной части OwnCloud. Мы используем и другие технологии, такие как C++ и Qt для настольных клиентов, Java для Android приложения и Objective-C для iOS, JavaScript для веб-интерфейса и многое другое. Но сердцем OwnCloud является серверный компонент, который базируется на PHP 5.3 или выше…



Было несколько причин для выбора PHP:
  • Основной задачей OwnCloud — предоставить всем желающим свой собственный облачный сервер. PHP является технологией, которая доступна в большинстве веб-серверов, операционных систем и платформ. Так же мы делаем хостинг серверов OwnCloud намного проще, потому что они написаны на PHP.
  • PHP — скриптовый язык, это значит, что один tar архив будет работать на всех платформах, и нет никаких сложных компиляций и сборок.
  • PHP очень хорошо известен. Много людей знакомы с PHP. И даже разработчики, которые не знают PHP, могут достаточно легко его изучить. Это очень важно для проекта с открытым исходным кодом, ведь уровень требований для участников должен быть как можно ниже.
  • PHP достаточно мощный и быстрый, если используется в правильном ключе. Много крупных веб-проектов, таких как Wikipedia, Facebook, WordPress и частично Yahoo написаны на PHP. Таким образом, вы можете сделать очень многое на нем. К сожалению так же относительно легко можно написать и плохой код. Но об этом чуть позже.
  • Существует огромная экосистема из библиотек, компонентов/драйверов доступных для PHP. Для проекта с открытым исходным кодом, как OwnCloud это очень здорово, потому что это означает, что вам не придется писать все с нуля. Мы стоим на плечах гигантов.


PHP не самый “хитовый” язык программирования в мире. На самом деле все наоборот. Он имеет относительно плохую репутацию. Я лично никогда не был большим поклонником в выборе технологий, основанных на том, что это «круто» или это «современно» или это «в моде». Я думаю, что есть разные технологии для различных областей, и они должны оцениваться объективно и выбирать их нужно без участия эмоций. Так что я не понимаю религиозные дискуссии, почему инструмент Х всегда лучше, чем технология Y. Я думаю, что все это верные технологии для работы, конечно после справедливой оценки о разумности их использования.

Так что я все еще очень доволен этим решением использовать PHP. До сих пор мы не встречали больших архитектурных или технических проблем, которые мы не смогли бы разрешить с PHP.

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

Некоторые очевидные недостатки:
  • Безопасность. PHP сам по себе не является безопасным, но представляет возможность написать прекрасный и безопасный код. PHP решил реализовать довольно наивный подход к безопасности и не слишком поддерживает разработчика в написании безопасного кода. Справедливости ради, все были наивны в вопросах веб-безопасности в 90-ые годы. Таким образом, не так много в PHP возможностей, помогающим разработчику написать безопасный код. К примеру, путаница с базами данных, до сих пор много людей не используют связываемые переменные, что возможно допускает появление SQL инъекции. И фильтрация входящих данных для XSS и другие возможные проблемы должны быть разрешены разработчиком вручную. Существуют расширения и библиотеки, которые помогут разрешить все эти проблемы, но они не являются частью языка/ядра или не решают проблему полностью.
  • компиляция/конфигурация. Просто ради веселья запустите скрипт ./configure для компиляции PHP и посмотрите на все опции компиляции. А теперь посмотрите на опции, которые можно установить в php.ini администратором сервера. С одной стороны это хорошо, потому, что администратор может включать и отключать львиную долю функций в PHP достаточно тривиальным способом. Но для разработчика PHP приложения, которое должно работать на всех доступных серверах с поддержкой PHP это кошмар. Вы никогда не знаете, какие функции доступны и активны. В OwnCloud у нас есть много кода, который зависит от окружающей среды и среды выполнения, и проверяет, что бы все работало как надо, или приспосабливается к ней по мере необходимости. Это, к сожалению не то, что вы называете стабильной платформой и хорошей ОС абстракцией.
  • Есть некоторые несоответствия в функциях и наименованиях классов. Иногда используется подчеркивание, иногда CamelCase. Некоторые возможности доступны в процедурном стиле, а некоторые имеют ОО API, а некоторые даже оба. Существует много того, что должно быть очищено.
  • Статическая типизация. Конечно это вопрос вкуса, но иногда мне очень хочется иметь больше статической типизации я действительно хотел бы иметь немного больше статической типизации в PHP. Угадайте, что делает следующий код, если у вас есть файл с именем «0» в каталоге

while ( ($filename = readdir($dh)) == true) $files[] = $filename;

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

Последняя статья в ArsTechnica и Apple продвигает к внедрению Swift как преемнику Objective-C, и тут я представляю, как следующее поколение PHP может и должно быть сделано.
Поддерживать обратную совместимость или исправлять свои недостатки? — Apple Swift

Сейчас существует старый, и честно говоря, очень наивный подход. Основная команда разработчиков языка программирования просто выпускает новую несовместимую версию, которая исправляет недостатки старой версии. Примерами являются Perl и Python. Проблема в том, что практически невозможно переписать большую часть программных проектов написанных на этих языках, для того, что бы сделать их совместимыми с новой версией. Таким образом, вы в конечном итоге работаете с двумя версиями языка программирования/фреймворка/приложения в течение очень долго времени. А некоторые приложения работают на старой версии и будут работать на старой версии. Различные библиотечные зависимости иногда доступны только для одной из версий.

Миграция является очень тяжелой и не может быть совершена по частям. Пожалуйста, посмотрите Perl6 и Python 2/3 как пример, каким ночным кошмаром это может стать. Оба существуют в течение очень долгого времени и много проектов «застряло» где то в середине миграционного пути.

Более позитивным примером является C++. Он все же очень отличается от C, но хорошо, что его можно использовать вперемешку внутри приложения. Таким образом С разработчики 90-ых могут использовать новые интересные C++ функции в одной части приложения, без необходимости переписывать все приложение с нуля.

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

Я надеюсь, PHP будет делать то, что делает возможным значительно развивать и совершенствовать язык, но, все же обеспечивая плавный опыт миграции, не так как с Perl и Python, когда выпустили совершенно новые несовместимые релизы.

Так же хорошим решением будет, если PHP 6 или 7 введет новый открывающий тег, например <?PHPNEXT вместо <?PHP. Оба режима полностью будут поддерживаться новой версией PHP и могут использоваться параллельно в одном и том же приложении или даже в одном и том же файле. А в PHPNEXT разделе будет использоваться новый и улучшенный синтаксис.

Вот несколько идей для улучшения, которые я хотел бы увидеть:
  • Безопасность. Не будет больше _GET, _POST, _SERVER массивов, вместо них появится правильный API, который можно будет использовать для фильтрации всех входящих данных. (Прим.переводчика: В данный момент существует filter_input, который поддерживается PHP 5 >= 5.2.0)
  • Базы данных. PHP поддерживает множество различных API базы данных. Некоторые из них очень старые, но они несовместимы в использовании. Все должны быть стандартизированы, чтобы существовал только один OO API. Я лично хотел бы увидеть PDO в качестве базиса.
  • 32/64bit. Любой, кто когда-либо пробовал написать PHP приложение, которое запускается на 32-битных или 64-битных ОС признают, что переменные, особенно целые, ведут себя по-разному. Я понимаю, что это отголоски C/C++, но это действительно плохая идея. Я не хочу иметь различные части кода, которые необходимо проверять независимо.
  • Уйдут safe_mode, open_basedir и другие древние концепции (Прим.переводчика: Опция safe_mode была помечена depricated в 5.3.0 и удалена в 5.4.0)
  • Удалится большинство опций конфигурации компиляции и выполнения. Все среды PHPNEXT должны быть максимально приближены и стабильны, настолько, насколько это возможно.
  • Типизация. Было бы здорово, если бы в PHP появилась дополнительная статическая типизация, такая, чтобы переменную можно было объявить как bool или int. А если в ней используется что-то иное, было брошено исключение.
  • Чтобы всегда использовались строки в юникоде


Некоторые из этих улучшений были реализованы в Hack, который является своего рода отдельной веткой PHP разработанной в Facebook. У Hack действительно интересная концепция, которая развивается в том же направлении. Они также используют новый тег "<hh", так что код можно вперемешку использовать в одном файле, а еще они улучшили типизацию. На данный момент не ясно, сколько сил Facebook намерен тратить на проект в будущем, чтобы развивать Hack дальше и как его примут за пределами Facebook. Так же я беспокоюсь, насколько они будут открыты для изменений, которые не важны для них, кто и как будет их регулировать. Я бы предпочел, официальный и более общий подход от PHP сообщества, которое будет частью одной из следующих основных релизов PHP.

Я надеюсь, что мечта о более современном и чистом PHP, включая плавный путь миграции, станет реальностью в ближайшие несколько лет.

Очевидно, что мы в OwnCloud не сможем начать мигрировать в этот новый режим PHP, до тех пор, пока до 95% всех PHP установок не начнут работать с новой версией. Это будет легко, но потребует дополнительных 3-5 лет.

Делая большие проекты, такие как WordPress или OwnCloud, фактически появится возможность переехать в более чистый и современный язык. Но что еще более важно PHP будет готов бросить вызов будущему.

UPD: добавил примечание, о удалении safe_mode в 5.4.0. Спасибо Sway за наводку :), так же добавил примечание о filter_input, thx AmdY за комментарий.

UPD2: исправил несколько ошибок в тексте, спасибо hDrummer за предоставленные замечания.
Поделиться публикацией

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

Комментарии 52
    +1
    До чтоб тебя услышали! =)
    Очень не хватает типизации нормальной (но необязательной). И, кстати, очень было бы хорошо если бы вынесли всякие str_xxx и array_xxx функции в отдельное api (javascript им в пример) удалив нафиг текущий бедлам. Ато там черт ногу сломит запоминая какая функция использует needle 1м параметром, а какая 2м. Да и именования некоторых функций, которые должны иметь префикс str_ или array_, но не имеют его, вызывают негодование.
    Кстати, safe mode убрали в 5.4 — (Из документации: 5.4.0 — safe_mode удален из PHP, генерирует фатальную ошибку E_CORE_ERROR при попытке включения)
      0
      RFC со статическим тайпхинтингом уже второй раз отзывается ее же автором. Не так то все просто. Хотя соглашусь, было бы здорово.

      По поводу выноса в отдельное API — вам никто не мешает вынести это добро в отдельный неймспейс алиасами и радоваться жизни. Ну или опять же pull реквест сделать. Меня либо это ни сколько не беспокоит. А в JS все объекты, так что там все чуть сложнее. Ну и да, есть же автокомплит в IDE, запоминать ничего не нужно. С именованием проблемы есть, но если у вас есть дельное предложение какое — RFC запилите.
        +1
        Да, отзывают, вот ссылка на отозванное RFC Scalar Type Hinting With Casts и тайпхинтинг для возвращаемых значений PHP RFC: Return Type Declarations
          0
          RFC для возвращаемых значений это просто тайпхинтинг для объектов. Он не позволяет прописать что функция возвращает строки или числа.
          0
          По поводу выноса в отдельное API — вам никто не мешает вынести это добро в отдельный неймспейс алиасами и радоваться жизни.

          Так речь не про то, что на PHP нельзя писать хороший код. Можно.
          Речь про то, как сделать PHP таким чтобы он подталкивал к написанию хорошего кода.
            0
            подталкивал к написанию хорошего кода.

            Проще сменить язык. Как по мне достойный механизм модулей/пакетов был бы намного более значительным подарком нежели такие вот мелочи.
              +1
              psr-4 и composer чем не устраивают? Зачем тут что-то тащить в язык?
                0
                В PHP вы никак не можете установить две версии разных пакетов. Никак. Если пакет A и B зависят от пакета C, причем для A C должно быть 1.0.* а для B 1,1,* то грусть тоска, нужно делать форк компонента A и править его под версию 1,1. Есть довольно распространенные пакеты, типа symfony/config, symfony/dependency-injection и т.д. которые используются только в рамках компонента и никак не пересекаются с работой приложения, посему если бы можно было ставить две версии разных модулей то это сделало бо задачу чуть проще.

                Так же это решило бы проблему автозагрузки функций, и вообще изоляцию всего и вся. И люди перестали бы для хелперов делать статические классы только потому что автозагрузки функций нету и нужно всегда их инклудить, даже если они не нужны.
                  0
                  В PHP вы никак не можете установить две версии разных пакетов. Никак
                  Есть такое, но ни разу с такой проблемой не сталкивался, да и не могу сказать, что подход npm с 100500 копий underscore мне нравится больше.
          –6
          Переход на Python или Ruby решит все описанные вами проблемы.
            +5
            Мыши плакали, кололись, но продолжали есть кактус
              +1
              Интересно, появится ли на хабре пост про php, в котором не будет этого комментария?
                –1
                Вполне возможно. Но его темой должно быть «Популярность PHP упала почти до нуля».
              +4
              Упомянутая чехарда с Python 2/3 еще более адский ад, чем некоторые шероховатости в php.
                –2
                1. Нет никакой чехарды, все используют 2.7, под него всё есть и никто не парится.
                2. Наличие хотя бы необязательной статической типизации — это очень важно, это не лёгкие шероховатости.
                  0
                  все используют 2.7

                  1. А вообще в природе есть 3.4. Вот зачем он нужен-то, если все пользуются 2.7?
                  Это и есть чехарда.
                  2. Под шероховатостями я имел ввиду некоторую несовместимость кода, написанного в каком-нить PHP4 и запущенного в 5.x. Таковых будет в разы меньше по сравнению с попытками запустить код для Python 2.7 в 3.x
                    +2
                    Нет никакой чехарды, все используют 2.7, под него всё есть и никто не парится.

                    Я принципиально всё новое пишу под Python>=3.3.
                +2
                По поводу выноса в отдельное API, вы о том, что бы скалярные типы вели себя как контейнерные классы? Если да, то подобное сейчас реализовано, правда в виде отдельной библиотеки, она позволяет регистрировать пользовательские классы как обработчики скалярных типов.

                И тогда можно писать что-то вроде:
                $str = 'Hello World!';
                echo $str->length();// 12
                $arr = $str->explode(' ');// $arr = ['Hello', 'World!'];

                и т.д., правда не очень понятно, что ждет эту библиотеку в будущем, и будет ли оно поддерживаться, так что я не очень себе представляю как использовать подобное в реальном живом проекте, и уж тем более в опенсоурс.

                upd: пруф
                +3
                Сколько лет этой статье?
                Вот апи для ухода от суперглобалов nl1.php.net/manual/en/function.filter-input.php
                PDO уже давно базис, хотя хотелка это не лучшая, заточенные под конкретную базу апишки дают больше функционала, например, асинхронные запросы. А вещи вроде mysql_ уже деприкейтид
                nl1.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode вовсе в деприкейтид со времён 5.3
                Типизация есть в пекле, вот только в ядро её не включают по своим причинам. Но если надо, используйте.
                  0
                  Вот апи для ухода от суперглобалов nl1.php.net/manual/en/function.filter-input.php


                  nl1.php.net/manual/en/filter.filters.sanitize.php — и вышел-таки снова на Дерибасовскую. Magic quotes, вид сбоку.
                    0
                    Наоборот, это как раз противоположность. Magic quotes по дефолту экранировали входные данные, здесь же инструментарий для его ручной обработки, т.к. автоматическое уже убрали и не портят входные данные. Что в этом плохого?
                      +1
                      Все плохо. При получении данных из реквеста никогда не должно быть необходимости делать addslashes или htmlspecialchars. Первое должен делать DBAL, второе — template engine, и оба из них никогда не должны ходить напрямую в реквест.
                        +1
                        Так DBAL и template engine это абстракции на пару уровней выше, язые же даёт необходимый инстрементарий для их реализации. doctrine + twig как раз делают то, что вы описали.
                          0
                          Этот «инструментарий» (sanitize-фильтры в filters) не нужен и даже вреден. Да и ни в doctrine, ни в twig, ни где-либо в symfony вы не найдете их использования.
                    +1
                    Статья написана 2 октября 2014 года.

                    По поводу суперглобалов, да API существует, однако и суперглобалы существуют. Автор предлагает полностью от них уйти, реализовав работу с ними только через API. «Выстрелить в ногу», даже начинающему разработчику будет намного сложнее.

                    По поводу PDO, да, нативные библиотеки дают больше функционала, но ведь можно было бы развить PDO до этого уровня, что бы PDO покрывал всевозможные хотелки. Тогда можно было бы уйти от нативных библиотек, и расширять работу своего проекта на несколько СУБД было бы легче. Так же благодаря этому, можно было бы склонять разработчиков к использованию связываемых переменных, с введением необязательной типизацией, и с удалением суперглобалов, можно было бы практически полностью забыть о существовании SQL инъекций.
                      0
                      Есть ещё exec, rm и даже eval. Зачем подстраиваться под нубов, они и при наличии плейсхолдеров смогут инъекцию протолкнуть, не воспользовавшись ими. PDO уже сейчас поддерживает prepare statment и кучу баз данных, так что в теории проблем нет, но он не может поддерживать фичи конкретных баз, потому что в одной они есть, в другой нет.
                        0
                        PDO уже сейчас поддерживает prepare statment

                        mysqli тоже поддерживает prepare statment
                    +5
                    Честно говоря, не уловил смысл статьи. Да есть какие-то всем понятные проблемы и пожелания. О чем говорит эта статья? О том, что есть всем понятные проблемы и пожелания?
                    Не говоря уж о том, что некоторые пункты неактуальны (safe_mode, бд) или спорны («безопасность»).
                      0
                      safe_mode, а не save_mode. И да, эта штука была удалена два релиза назад: php.net/manual/en/features.safe-mode.php
                        +4
                        Эх… я уже лет 15 пишу на PHP и, мне кажется, будущего у него нет. Ну то есть, он никуда не исчезнет, но красивым и самосогласованным языком ему уже не стать. Просто всё больше проектов будут с самого начала выбирать другие языки.

                        Если даже загрузчик Symfony 3 собираются писать на Go (https://github.com/symfony/symfony/issues/11901#issuecomment-55377167), о каком будущем языка можно говорить?
                          +1
                          Не загрузчик а пока только валидатор окружения и обертка для загрузчика написанного на php. И это логично, просто бинарник, который не требует никаких зависимостей. Для выполнения php скриптов нам все же нужно что бы в системе был установлен php.
                            +1
                            Пишу на нём только 13 лет, но вижу, как из гадкого утёнка вылепляется, наконец, нечто удобное и приятное. Composer вообще переворот устроил. Я уже несколько лет подумывал о смене платформы ( PHP далеко не первый, не последний и не единственный язык в моей практике), но в последние пару лет такое желание вдруг быстро пропало :)
                              +1
                              Эх… я уже лет 15 пишу на PHP и, мне кажется, будущего у него нет.

                              Прикол в том, что так кажется все эти 15 лет. И все эти 15 лет у него нет будущего. И я так думаю еще очень долго у него не будет будущего…
                              +6
                              while ( ($filename = readdir($dh)) == true) $files[] = $filename;

                              Просто надо бить по рукам за такой код. В доке написано, что возращает false если больше файлов нет, значит надо проверять на false и про тип не забыть:

                              while ( ($filename = readdir($dh)) !== false) $files[] = $filename;

                                0
                                На самом деле, вы зря акцентируете на этом внимание, потому что автор как раз и говорит, что этот код не работает с файлом с именем «0» в директории. Кстати говоря, похожие проблемы (были?) у парсера хабра.
                                  +2
                                  Конечно не работает, ведь пример написан с логической ошибкой, а мой работает, в данном случае проблема не в языке

                                  readdir вообще никогда булевую истину не возращает
                                    0
                                    Я ещё раз хотел бы повторить: автор перечисляет недостатки PHP, приводя в пример цикл с чтением файла из директории (то есть, безусловно, автор, как и большинство более-менее опытных программистов на PHP в курсе, что так делать не надо).
                                    Из-за того, что строка «0» воспринимается в PHP, как false, нужно сравнивать через тройное равенство с false, что выглядит как-то не очень, и во многих случаях забывается даже теми разработчиками, которые на эти грабли уже наступали. В этом и есть один из «системных» недостатков PHP, о котором говорит автор.
                                      +1
                                      Не считаю это недостатком языка, это фишка и я ей постоянно пользовался когда писал на php. А автор больше похож на профана в этой области.
                                        0
                                        Приходится выбирать. Или мы считаем строковый ноль за false и тогда каждый раз проводим строгую проверку, или считаем строковый ноль за true и тогда каждый раз при получении строковых данных проходим промежуточное преобразование в int и только потом int в bool. Первое поведение, ИМХО, логичнее. Второе в том же JS, например, порождает куда менее красивый и логичный код.
                                    +2
                                    Согласен, но тут скорее неявной ошибкой будет использовать:
                                    while ($filename = readdir($handle)) { $files[] = $filename; }

                                    И это не единственный пример, казалось бы о подобных вещах должен знать любой школьник junior, но все равно периодически встречается… Например тот же
                                    empty($string);
                                    В том ключе, когда разработчик рассчитывает, что он отфильтрует только false, '', и null.
                                    0
                                    мне кажется автор(Frank Karlitschek если верить переводчику) не очень хорошо изучил php и, в меру своего незнания базовых концепций(особенно показателя скорость/результат) бросается «умными» словами типа Perl, Python, Swift и Hack. Просто делать неподкрепленные и неаргументированные выводы типа «Все должны быть стандартизированы, чтобы только один OO API существовал.» может на самом деле — каждый! Хотя непонятно насколько это является мыслью автора а не «слишком вольной» интерпретацией переводчика. Так или иначе на Хабре я все чаще начинаю видеть какую-то херню под предлогом «это не я писал, это все они — я только вольно перевел»!
                                      +1
                                      «Все должны быть стандартизированы, чтобы только один OO API существовал.», речь идет об API для баз данных. В оригинале это звучит так «Everything should be standardized so that only one OO interface exists.».

                                      Речь идет об API которое могло бы быть основано на PDO, расширяющее функционал PDO до уровня нативных драйверов (like mysqli, pgsql и т.д.). При этом необходимость в таких нативных драйверах отпадет сама собой. Тогда можно было бы не строить кучу абстракций в коде позволяющих запустить его в разными СУБД.

                                      Что касается «слишком вольного» перевода, у вас всегда есть возможность сравнить его с оригиналом, если в моем переводе где-то присутствуют ошибки, либо он расходится с мнением и мыслью автора, я всегда с радостью приму любой отзыв\критику и исправлю свои ошибки.

                                      Статью я перевел, потому что мне понравились мысли автора относительно того, каким автор видит будущее. И да, автор этой статьи Frank Karlitschek. (если не верить переводчику, можно заглянуть в оригинал, так же ссылка на оригинал представлена в переводе в двух местах)
                                        +2
                                        Автор статьи — разработчик ownCloud. Может быть он, конечно, «не очень хорошо изучил php», но тогда непонятно, кем надо быть, чтобы хорошо его изучить.
                                        0
                                        В PHP помимо указанного хватает проблем, не решаемых без статической типизации. Например, насильное приведение numeric ключей массивов к числам, что в сочетании с не к месту применённым array_merge приводит к очень неожиданным проблемам. Уродства не меньше, например, синтаксис получения значения из массива, с дефолтом если значения нет (с error handler'ом хаками типа @ не воспользоваться), отсутствие слайсов, псевдофункциональные array_map итп.
                                          +2
                                          новый открывающий тег, например <?PHPNEXT вместо <?PHP

                                          Надеюсь такого ужаса не будет.
                                            0
                                            А мне кажется неплохая идея для версионирования php. Можно не phpnext, а просто php7.
                                            –1
                                            Это немного похоже на то: давайте не будем учить хороших программистов, а сделаем язык как можно более сложным, чтобы они сами отвалились. Меж тем, по моему опыту, не так много проектов требуют гуру программистов. Я за то чтобы учить нормально кодить, а не вынуждать к этому усложняя язык.
                                              –3
                                              Вот еще вариант мнений pyha.ru/forum/topic/8751
                                                0
                                                Мне очень иногда не хватает перегрузки операторов… Было бы очень здорово писать что-то вроде: if(Object1 >= Object2)
                                                  0
                                                  pecl.php.net/package/operator если вам так хочется. Так же nikic предлагал ввести интерфейс Comparable.

                                                  Но вообще перегрузка операторов в PHP как по мне ужасная идея…
                                                    0
                                                    Было бы замечательно иметь что-то вроде js-овского valueOf… ибо __toString например php будет вызывать в случае со сравнением только если один из аргументов является строкой… и это согласитесь кастыль.
                                                      0
                                                      Спасибо вам за информацию. Хватало бы кармы, плюсанул бы от души :)

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

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