Comments 52
До чтоб тебя услышали! =)
Очень не хватает типизации нормальной (но необязательной). И, кстати, очень было бы хорошо если бы вынесли всякие str_xxx и array_xxx функции в отдельное api (javascript им в пример) удалив нафиг текущий бедлам. Ато там черт ногу сломит запоминая какая функция использует needle 1м параметром, а какая 2м. Да и именования некоторых функций, которые должны иметь префикс str_ или array_, но не имеют его, вызывают негодование.
Кстати, safe mode убрали в 5.4 — (Из документации: 5.4.0 — safe_mode удален из PHP, генерирует фатальную ошибку E_CORE_ERROR при попытке включения)
Очень не хватает типизации нормальной (но необязательной). И, кстати, очень было бы хорошо если бы вынесли всякие str_xxx и array_xxx функции в отдельное api (javascript им в пример) удалив нафиг текущий бедлам. Ато там черт ногу сломит запоминая какая функция использует needle 1м параметром, а какая 2м. Да и именования некоторых функций, которые должны иметь префикс str_ или array_, но не имеют его, вызывают негодование.
Кстати, safe mode убрали в 5.4 — (Из документации: 5.4.0 — safe_mode удален из PHP, генерирует фатальную ошибку E_CORE_ERROR при попытке включения)
RFC со статическим тайпхинтингом уже второй раз отзывается ее же автором. Не так то все просто. Хотя соглашусь, было бы здорово.
По поводу выноса в отдельное API — вам никто не мешает вынести это добро в отдельный неймспейс алиасами и радоваться жизни. Ну или опять же pull реквест сделать. Меня либо это ни сколько не беспокоит. А в JS все объекты, так что там все чуть сложнее. Ну и да, есть же автокомплит в IDE, запоминать ничего не нужно. С именованием проблемы есть, но если у вас есть дельное предложение какое — RFC запилите.
По поводу выноса в отдельное API — вам никто не мешает вынести это добро в отдельный неймспейс алиасами и радоваться жизни. Ну или опять же pull реквест сделать. Меня либо это ни сколько не беспокоит. А в JS все объекты, так что там все чуть сложнее. Ну и да, есть же автокомплит в IDE, запоминать ничего не нужно. С именованием проблемы есть, но если у вас есть дельное предложение какое — RFC запилите.
Да, отзывают, вот ссылка на отозванное RFC Scalar Type Hinting With Casts и тайпхинтинг для возвращаемых значений PHP RFC: Return Type Declarations
По поводу выноса в отдельное API — вам никто не мешает вынести это добро в отдельный неймспейс алиасами и радоваться жизни.
Так речь не про то, что на PHP нельзя писать хороший код. Можно.
Речь про то, как сделать PHP таким чтобы он подталкивал к написанию хорошего кода.
подталкивал к написанию хорошего кода.
Проще сменить язык. Как по мне достойный механизм модулей/пакетов был бы намного более значительным подарком нежели такие вот мелочи.
psr-4 и composer чем не устраивают? Зачем тут что-то тащить в язык?
В PHP вы никак не можете установить две версии разных пакетов. Никак. Если пакет A и B зависят от пакета C, причем для A C должно быть 1.0.* а для B 1,1,* то грусть тоска, нужно делать форк компонента A и править его под версию 1,1. Есть довольно распространенные пакеты, типа symfony/config, symfony/dependency-injection и т.д. которые используются только в рамках компонента и никак не пересекаются с работой приложения, посему если бы можно было ставить две версии разных модулей то это сделало бо задачу чуть проще.
Так же это решило бы проблему автозагрузки функций, и вообще изоляцию всего и вся. И люди перестали бы для хелперов делать статические классы только потому что автозагрузки функций нету и нужно всегда их инклудить, даже если они не нужны.
Так же это решило бы проблему автозагрузки функций, и вообще изоляцию всего и вся. И люди перестали бы для хелперов делать статические классы только потому что автозагрузки функций нету и нужно всегда их инклудить, даже если они не нужны.
Переход на Python или Ruby решит все описанные вами проблемы.
Мыши плакали, кололись, но продолжали есть кактус
Упомянутая чехарда с Python 2/3 еще более адский ад, чем некоторые шероховатости в php.
1. Нет никакой чехарды, все используют 2.7, под него всё есть и никто не парится.
2. Наличие хотя бы необязательной статической типизации — это очень важно, это не лёгкие шероховатости.
2. Наличие хотя бы необязательной статической типизации — это очень важно, это не лёгкие шероховатости.
все используют 2.7
1. А вообще в природе есть 3.4. Вот зачем он нужен-то, если все пользуются 2.7?
Это и есть чехарда.
2. Под шероховатостями я имел ввиду некоторую несовместимость кода, написанного в каком-нить PHP4 и запущенного в 5.x. Таковых будет в разы меньше по сравнению с попытками запустить код для Python 2.7 в 3.x
Нет никакой чехарды, все используют 2.7, под него всё есть и никто не парится.
Я принципиально всё новое пишу под Python>=3.3.
По поводу выноса в отдельное API, вы о том, что бы скалярные типы вели себя как контейнерные классы? Если да, то подобное сейчас реализовано, правда в виде отдельной библиотеки, она позволяет регистрировать пользовательские классы как обработчики скалярных типов.
И тогда можно писать что-то вроде:
и т.д., правда не очень понятно, что ждет эту библиотеку в будущем, и будет ли оно поддерживаться, так что я не очень себе представляю как использовать подобное в реальном живом проекте, и уж тем более в опенсоурс.
upd: пруф
И тогда можно писать что-то вроде:
$str = 'Hello World!';echo $str->length();// 12$arr = $str->explode(' ');// $arr = ['Hello', 'World!'];и т.д., правда не очень понятно, что ждет эту библиотеку в будущем, и будет ли оно поддерживаться, так что я не очень себе представляю как использовать подобное в реальном живом проекте, и уж тем более в опенсоурс.
upd: пруф
Сколько лет этой статье?
Вот апи для ухода от суперглобалов 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
Типизация есть в пекле, вот только в ядро её не включают по своим причинам. Но если надо, используйте.
Вот апи для ухода от суперглобалов 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
Типизация есть в пекле, вот только в ядро её не включают по своим причинам. Но если надо, используйте.
Вот апи для ухода от суперглобалов nl1.php.net/manual/en/function.filter-input.php
nl1.php.net/manual/en/filter.filters.sanitize.php — и вышел-таки снова на Дерибасовскую. Magic quotes, вид сбоку.
Наоборот, это как раз противоположность. Magic quotes по дефолту экранировали входные данные, здесь же инструментарий для его ручной обработки, т.к. автоматическое уже убрали и не портят входные данные. Что в этом плохого?
Все плохо. При получении данных из реквеста никогда не должно быть необходимости делать addslashes или htmlspecialchars. Первое должен делать DBAL, второе — template engine, и оба из них никогда не должны ходить напрямую в реквест.
Статья написана 2 октября 2014 года.
По поводу суперглобалов, да API существует, однако и суперглобалы существуют. Автор предлагает полностью от них уйти, реализовав работу с ними только через API. «Выстрелить в ногу», даже начинающему разработчику будет намного сложнее.
По поводу PDO, да, нативные библиотеки дают больше функционала, но ведь можно было бы развить PDO до этого уровня, что бы PDO покрывал всевозможные хотелки. Тогда можно было бы уйти от нативных библиотек, и расширять работу своего проекта на несколько СУБД было бы легче. Так же благодаря этому, можно было бы склонять разработчиков к использованию связываемых переменных, с введением необязательной типизацией, и с удалением суперглобалов, можно было бы практически полностью забыть о существовании SQL инъекций.
По поводу суперглобалов, да API существует, однако и суперглобалы существуют. Автор предлагает полностью от них уйти, реализовав работу с ними только через API. «Выстрелить в ногу», даже начинающему разработчику будет намного сложнее.
По поводу PDO, да, нативные библиотеки дают больше функционала, но ведь можно было бы развить PDO до этого уровня, что бы PDO покрывал всевозможные хотелки. Тогда можно было бы уйти от нативных библиотек, и расширять работу своего проекта на несколько СУБД было бы легче. Так же благодаря этому, можно было бы склонять разработчиков к использованию связываемых переменных, с введением необязательной типизацией, и с удалением суперглобалов, можно было бы практически полностью забыть о существовании SQL инъекций.
Есть ещё exec, rm и даже eval. Зачем подстраиваться под нубов, они и при наличии плейсхолдеров смогут инъекцию протолкнуть, не воспользовавшись ими. PDO уже сейчас поддерживает prepare statment и кучу баз данных, так что в теории проблем нет, но он не может поддерживать фичи конкретных баз, потому что в одной они есть, в другой нет.
Честно говоря, не уловил смысл статьи. Да есть какие-то всем понятные проблемы и пожелания. О чем говорит эта статья? О том, что есть всем понятные проблемы и пожелания?
Не говоря уж о том, что некоторые пункты неактуальны (safe_mode, бд) или спорны («безопасность»).
Не говоря уж о том, что некоторые пункты неактуальны (safe_mode, бд) или спорны («безопасность»).
safe_mode, а не save_mode. И да, эта штука была удалена два релиза назад: php.net/manual/en/features.safe-mode.php
Эх… я уже лет 15 пишу на PHP и, мне кажется, будущего у него нет. Ну то есть, он никуда не исчезнет, но красивым и самосогласованным языком ему уже не стать. Просто всё больше проектов будут с самого начала выбирать другие языки.
Если даже загрузчик Symfony 3 собираются писать на Go (https://github.com/symfony/symfony/issues/11901#issuecomment-55377167), о каком будущем языка можно говорить?
Если даже загрузчик Symfony 3 собираются писать на Go (https://github.com/symfony/symfony/issues/11901#issuecomment-55377167), о каком будущем языка можно говорить?
Не загрузчик а пока только валидатор окружения и обертка для загрузчика написанного на php. И это логично, просто бинарник, который не требует никаких зависимостей. Для выполнения php скриптов нам все же нужно что бы в системе был установлен php.
Пишу на нём только 13 лет, но вижу, как из гадкого утёнка вылепляется, наконец, нечто удобное и приятное. Composer вообще переворот устроил. Я уже несколько лет подумывал о смене платформы ( PHP далеко не первый, не последний и не единственный язык в моей практике), но в последние пару лет такое желание вдруг быстро пропало :)
Эх… я уже лет 15 пишу на PHP и, мне кажется, будущего у него нет.
Прикол в том, что так кажется все эти 15 лет. И все эти 15 лет у него нет будущего. И я так думаю еще очень долго у него не будет будущего…
while ( ($filename = readdir($dh)) == true) $files[] = $filename;Просто надо бить по рукам за такой код. В доке написано, что возращает false если больше файлов нет, значит надо проверять на false и про тип не забыть:
while ( ($filename = readdir($dh)) !== false) $files[] = $filename;
На самом деле, вы зря акцентируете на этом внимание, потому что автор как раз и говорит, что этот код не работает с файлом с именем «0» в директории. Кстати говоря, похожие проблемы (были?) у парсера хабра.
Конечно не работает, ведь пример написан с логической ошибкой, а мой работает, в данном случае проблема не в языке
readdir вообще никогда булевую истину не возращает
readdir вообще никогда булевую истину не возращает
Я ещё раз хотел бы повторить: автор перечисляет недостатки PHP, приводя в пример цикл с чтением файла из директории (то есть, безусловно, автор, как и большинство более-менее опытных программистов на PHP в курсе, что так делать не надо).
Из-за того, что строка «0» воспринимается в PHP, как false, нужно сравнивать через тройное равенство с false, что выглядит как-то не очень, и во многих случаях забывается даже теми разработчиками, которые на эти грабли уже наступали. В этом и есть один из «системных» недостатков PHP, о котором говорит автор.
Из-за того, что строка «0» воспринимается в PHP, как false, нужно сравнивать через тройное равенство с false, что выглядит как-то не очень, и во многих случаях забывается даже теми разработчиками, которые на эти грабли уже наступали. В этом и есть один из «системных» недостатков PHP, о котором говорит автор.
Не считаю это недостатком языка, это фишка и я ей постоянно пользовался когда писал на php. А автор больше похож на профана в этой области.
Приходится выбирать. Или мы считаем строковый ноль за false и тогда каждый раз проводим строгую проверку, или считаем строковый ноль за true и тогда каждый раз при получении строковых данных проходим промежуточное преобразование в int и только потом int в bool. Первое поведение, ИМХО, логичнее. Второе в том же JS, например, порождает куда менее красивый и логичный код.
Согласен, но тут скорее неявной ошибкой будет использовать:
И это не единственный пример, казалось бы о подобных вещах должен знать любойшкольник junior, но все равно периодически встречается… Например тот же
В том ключе, когда разработчик рассчитывает, что он отфильтрует только false, '', и null.
while ($filename = readdir($handle)) { $files[] = $filename; }И это не единственный пример, казалось бы о подобных вещах должен знать любой
empty($string);В том ключе, когда разработчик рассчитывает, что он отфильтрует только false, '', и null.
мне кажется автор(Frank Karlitschek если верить переводчику) не очень хорошо изучил php и, в меру своего незнания базовых концепций(особенно показателя скорость/результат) бросается «умными» словами типа Perl, Python, Swift и Hack. Просто делать неподкрепленные и неаргументированные выводы типа «Все должны быть стандартизированы, чтобы только один OO API существовал.» может на самом деле — каждый! Хотя непонятно насколько это является мыслью автора а не «слишком вольной» интерпретацией переводчика. Так или иначе на Хабре я все чаще начинаю видеть какую-то херню под предлогом «это не я писал, это все они — я только вольно перевел»!
«Все должны быть стандартизированы, чтобы только один OO API существовал.», речь идет об API для баз данных. В оригинале это звучит так «Everything should be standardized so that only one OO interface exists.».
Речь идет об API которое могло бы быть основано на PDO, расширяющее функционал PDO до уровня нативных драйверов (like mysqli, pgsql и т.д.). При этом необходимость в таких нативных драйверах отпадет сама собой. Тогда можно было бы не строить кучу абстракций в коде позволяющих запустить его в разными СУБД.
Что касается «слишком вольного» перевода, у вас всегда есть возможность сравнить его с оригиналом, если в моем переводе где-то присутствуют ошибки, либо он расходится с мнением и мыслью автора, я всегда с радостью приму любой отзыв\критику и исправлю свои ошибки.
Статью я перевел, потому что мне понравились мысли автора относительно того, каким автор видит будущее. И да, автор этой статьи Frank Karlitschek. (если не верить переводчику, можно заглянуть в оригинал, так же ссылка на оригинал представлена в переводе в двух местах)
Речь идет об API которое могло бы быть основано на PDO, расширяющее функционал PDO до уровня нативных драйверов (like mysqli, pgsql и т.д.). При этом необходимость в таких нативных драйверах отпадет сама собой. Тогда можно было бы не строить кучу абстракций в коде позволяющих запустить его в разными СУБД.
Что касается «слишком вольного» перевода, у вас всегда есть возможность сравнить его с оригиналом, если в моем переводе где-то присутствуют ошибки, либо он расходится с мнением и мыслью автора, я всегда с радостью приму любой отзыв\критику и исправлю свои ошибки.
Статью я перевел, потому что мне понравились мысли автора относительно того, каким автор видит будущее. И да, автор этой статьи Frank Karlitschek. (если не верить переводчику, можно заглянуть в оригинал, так же ссылка на оригинал представлена в переводе в двух местах)
Автор статьи — разработчик ownCloud. Может быть он, конечно, «не очень хорошо изучил php», но тогда непонятно, кем надо быть, чтобы хорошо его изучить.
В PHP помимо указанного хватает проблем, не решаемых без статической типизации. Например, насильное приведение numeric ключей массивов к числам, что в сочетании с не к месту применённым array_merge приводит к очень неожиданным проблемам. Уродства не меньше, например, синтаксис получения значения из массива, с дефолтом если значения нет (с error handler'ом хаками типа @ не воспользоваться), отсутствие слайсов, псевдофункциональные array_map итп.
новый открывающий тег, например <?PHPNEXT вместо <?PHP
Надеюсь такого ужаса не будет.
Это немного похоже на то: давайте не будем учить хороших программистов, а сделаем язык как можно более сложным, чтобы они сами отвалились. Меж тем, по моему опыту, не так много проектов требуют гуру программистов. Я за то чтобы учить нормально кодить, а не вынуждать к этому усложняя язык.
Вот еще вариант мнений pyha.ru/forum/topic/8751
Мне очень иногда не хватает перегрузки операторов… Было бы очень здорово писать что-то вроде: if(Object1 >= Object2)
pecl.php.net/package/operator если вам так хочется. Так же nikic предлагал ввести интерфейс Comparable.
Но вообще перегрузка операторов в PHP как по мне ужасная идея…
Но вообще перегрузка операторов в PHP как по мне ужасная идея…
Sign up to leave a comment.
Возможное будущее для PHP