Комментарии 44
[RFC] Direct execution opcode file without php source code file
Ещё в архивчик запаковать… или phar адаптировать, чтоб php-fpm с ним работать мог.
Да, возможно в опенсорсе подобные решения создадут проблемы, но для коммерческой разработки — большой плюс.
Будет намного проще отдать клиенту "код" без костылей в виде обфускации (всё равно можно развернуть обратно). Текущие решения вроде Ioncube не работают с современными версиями php (7.4 / 8.0).
Тем более, в мире C++ (и не только) и скомпилированных библиотек с этим нет никаких проблем: библиотека поставляется вместе с заголовочником, схема отлаженная. Возможно, в php появится похожая возможность.
во всякие вордпрессы юзеры будут сами себе ставить кучу малвари
Это происходит и сейчас, некоторые разработчики скачивают "крякнутые" плагины/темы и т.п. и устанавливают их, даже не открывая сорцы.
Ломают. И в нашем случае, скорее всего, научатся.
Тут вопрос в возможности использования такого декомпилированного кода и целесообразности таких действий.
Подождём, понаблюдаем. Но если появится нативный инструмент, который будет эту задачу решать и решать её хорошо, то пользы от этого будет точно больше, чем проблем. Всё же, в команде internals достаточно хороших и адекватных специалистов.
Для inhouse-разработки смысла в пред-компиляции немного, усложнится SDLC.
Разве что поверх PHP появится аналог Typescript.
Разве что поверх PHP появится аналог Typescript.
Интересная мысль. Правада, скорее не не аналог Typescript, а аналог Scala, Kotlin, JPython и т. п.
Всё верно.
Я рассуждал с мыслью о платных коробках. Когда при продаже ПО клиенту можно не переживать, что через несколько месяцев он будет выложен на какой-нибудь warez-помойке в комплекте с парочкой троянов.
Иногда условия бизнеса не позволяют создать какое-то SAAS-решение, клиент борется за то, чтобы софт был на его сервере и под его контролем.
то пользы от этого будет точно больше, чем проблем
Прощай использование __DIR__, __FILE__ и прочих… Совсем нет проблем, ага, учитывая что сейчас сложно найти код не использующий эти константы (например require __DIR__ .'/vendor/autoload.php')
А вот польза сомнительная. Насчет "защиты от чужих глаз" уж точно — декомпилировать опкоды PHP по моему уже давно умеют, если не ошибаюсь.
Почему прощай-то? Просто компилировать нужно будет сразу в продакшен-путях: chroot, docker и ко.
В bcompiler решали подобные проблемы добавлением заголовков в бинарные файлы. В этих заголовках и были прописаны пути до файлов и прочая метаинформация.
Насчёт __FILE__ и __DIR__ не помню, но ошибки точно вываливались с теми путями, которые были на машине разработчика в момент компиляции :)
Кроме того, нет особого смысла байткодить все файлы. Всякие штуки вроде require __DIR__ .'/vendor/autoload.php' можно было бы и вынести
Текущие решения вроде Ioncube не работают с современными версиями php (7.4 / 8.0).
C PHP 8 — еще нет, с 7.4 — уже какое-то заметное время да. Я по работе занимаюсь в том числе тестированием совместимости продукта с IonCube, нахожусь в прямом контакте с их технарями, и они адекватно и достаточно оперативно реагируют на проблемы в рантайме… если отправить им PoC на косяк декодера, фикс иногда прилетает через 24 часа, и через 48 уходит в релиз. Нормальные ребята, в общем.
SomeClass.min.php.
itsgoingd/clockwork v5.0 — Отладочная панель и расширение для Chrome
Не только для Chrome!
Добавлена поддержка PHP 8 в Yii 1
Респект таким ребятам!
PDOStatement не расширить. Убогий синтаксис плейсхолдеров. Коллекции — руками.
А внедрение значения в поля объекта без вызова конструктора при fetch в объект — это ж совершенно непредсказуемое поведение.
SPL types так и остался экспериментальным. SplBool — шикарная же идея, чтобы писать if ($object).
Зачем алгебра в языке для middleware? Зачем делать из скриптового языка компилируемый? Работа с СУБД нужна.
Разве юзерленд либы не решают все проблемы с СУБД?
Любую проблему можно решить введением дополнительного уровня абстракции кроме проблемы слишком большого количества уровней абстракции.
Когда нужен тюнинг запросов, например, ничего никто не решает. Абстракции не бесплатные.
PDO предоставляет PDOStatement для запросов, без вариантов. Не переопределить, не расширить.
Почему PDOStatement делает и присваивание параметров, и выполнение запроса, и формирование результата, что за нарушение SRP?
Результат fetchAll() — массив объектов или массивов, без вариантов. А когда нет записей — пустой массив, без вариантов. И зачем он такой, fetchAll() с массивом объектов — что за смесь бульдога с носорогом?
А чем плох массив объектов? Какие альтернативы?
Коллекции объектов же а-ля Doctrine или Eloquent Collection. Возможно виртуальные на итераторах/генераторах. А может что-то из мира асинхронщины с колбэками )
Ааа, понял теперь о чем речь. Ну, то есть по факту о том, что нет коллекций из коробки?
Просто в чем проблема делать new ArrayCollection(PDOStatement::fetchAll)?
То, что здесь хорошо было бы дженерики — это понятно. Непонятно в чем проблема использования коллекций Doctrine/Eloquent.
Это моё предположение, что имел в виду Grikdotnet я точно не знаю.
по факту о том, что нет коллекций из коробки?
Тем, что нет ничего. Тупая процедурщина, как в php3. Как 20 лет назад написали fetch в массив — с тем php и похоронят.
Дженерики — то отдельная тема. Хардкодить этого монстра PDOStatement — ошибка дизайна. Надо инъектить в PDO наследника PDOStatement, который бы позволял переопределить fetch.
Полиморфизм? Inversion of Control? Liskov substitution? Нет, не слышали!
del
Надо инъектить в PDO наследника PDOStatement, который бы позволял переопределить fetch.
А что мешает так сделать и переопределить fetch как надо?
www.php.net/manual/ru/pdo.setattribute.php
Вернулись к тезису о процедурном программировании. Пользоваться PDO неудобно. Нужно изучить десятки констант и неочевидное поведение.
Доработка PDO — это то, что было бы востребовано во всех приложениях. Намного более востребовано в мире, чем те же дженерики.
В подавляющем большинстве современного ПО PDO сидит где-то внутри ORM (Doctrine/Cycle/Eloquent/etc) и использовать его напрямую зачастую даже вредно (в рамках DM паттерна с наличием Identity Map, например).
Так что выбирая между PDO vs Generics (ну вдруг так случится), то какими бы не были убедительными аргументы в пользу PDO — юзкейсов с дженериками на порядки больше, т.к. это конструкция языка, которая "протекает" и в бизнес-логику, которую невозможно покрыть библиотечным функционалом, а не низкоуровневый драйвер работы с БД, который, при работе через фреймы, изучается лишь "для галочки" и никогда вообще не используется.
чем плох массив объектов?
PDOStatement просят fetch в объект, а оно возвращает массив. Это ошибка дизайна.
Массив — это процедурное программирование.
Логично вернуть специальный объект типа PdoResultSet, расширяющий SPLFixedArray. Или как в fetchObject, в параметре принимать пользовательский тип для коллекции.
метод bindParam() — передача констант по ссылке, ниче так для php8? :)
асинхронный режим запросов, который нельзя подцепить к libevent-циклу — зачем он, вообще?
Должны быть низкоуровневые функции
Как я понимаю, речь о том, что они не очень удобные и, как бы это, правильные что ли. И абстракции не избавляют нас от трейсов с вызовами этих низкоуровневых функций.
а так-то Феррара их proof of concept написал лет под 10 назад, только тормозят жутко
Руководство по разработке расширений для PHP от Zend
Ох ты ж, какая годнота!
PHP-Дайджест № 194 (1 – 14 декабря 2020)