Тем, что нет ничего. Тупая процедурщина, как в php3. Как 20 лет назад написали fetch в массив — с тем php и похоронят.
Дженерики — то отдельная тема. Хардкодить этого монстра PDOStatement — ошибка дизайна. Надо инъектить в PDO наследника PDOStatement, который бы позволял переопределить fetch.
Полиморфизм? Inversion of Control? Liskov substitution? Нет, не слышали!
PDOStatement просят fetch в объект, а оно возвращает массив. Это ошибка дизайна.
Массив — это процедурное программирование.
Логично вернуть специальный объект типа PdoResultSet, расширяющий SPLFixedArray. Или как в fetchObject, в параметре принимать пользовательский тип для коллекции.
С этим есть одна проблема. Чтобы внедрять AR-объекты в инфраструктурные сервисы персистентности типа репозиториев, нужно создавать их где-то еще. А негде. Приходится жертвовать независимостью слоя персистентности, и хардкодить ActiveRecordModel::find(); в нем. А что делать, хотя бы по слоям не размазывается.
дженерики Никита пытался сделать очень упорно, но не выходит для динамического языка, нормально работает только без проверки в runtime — слишком дорого
а так-то Феррара их proof of concept написал лет под 10 назад, только тормозят жутко
а mysqli — это вообще песня!
метод bindParam() — передача констант по ссылке, ниче так для php8? :)
асинхронный режим запросов, который нельзя подцепить к libevent-циклу — зачем он, вообще?
Это ж классика афоризма :)
Любую проблему можно решить введением дополнительного уровня абстракции кроме проблемы слишком большого количества уровней абстракции.
Когда нужен тюнинг запросов, например, ничего никто не решает. Абстракции не бесплатные.
PDO предоставляет PDOStatement для запросов, без вариантов. Не переопределить, не расширить.
Почему PDOStatement делает и присваивание параметров, и выполнение запроса, и формирование результата, что за нарушение SRP?
Результат fetchAll() — массив объектов или массивов, без вариантов. А когда нет записей — пустой массив, без вариантов. И зачем он такой, fetchAll() с массивом объектов — что за смесь бульдога с носорогом?
Термин «модель» я использую в оригинальном значении — domain, бизнес-логика.
В Yii «model» — мапинг на таблицу, это можно считать слоем персистентности. По терминологии clean architecture это Interface Adapters.
Если для слоя персистентности создать дополнительный уровень абстракции — да, AR надо передавать в него, но я бы не называл это моделями.
Между слоями передаются value object, конечно.
В ActiveRecord в Yii нарушение OCP заложено на уровне архитектуры.
$query = ActiveRecordModel::find(); — это прямое нарушение сразу SRP, OCP и IoC.
Чтобы уйти от связанности кода, надо использовать AR как persistance layer в своих доменных моделях. Композиция — считать AR сервисом персистентности, и передавать его в модели как зависимости.
Это может быть нужно авторам платных коробок.
Для inhouse-разработки смысла в пред-компиляции немного, усложнится SDLC.
Разве что поверх PHP появится аналог Typescript.
Жаль только, что пока космические корабли бороздят просторы вселенной, самые востребованные части php — PDO и mysqli, остаются кучей мусора, нарушают и SOLID, и стандарты языка.
PDOStatement не расширить. Убогий синтаксис плейсхолдеров. Коллекции — руками.
А внедрение значения в поля объекта без вызова конструктора при fetch в объект — это ж совершенно непредсказуемое поведение.
SPL types так и остался экспериментальным. SplBool — шикарная же идея, чтобы писать if ($object).
Зачем алгебра в языке для middleware? Зачем делать из скриптового языка компилируемый? Работа с СУБД нужна.
Да, проблема, безусловно, есть — я не смог донести, и пытаюсь решить проблему в будущем.
Ответ на вопрос «зачем?» требует описание бизнес-логики. Простите, не могу раскрывать детали конкретных ситуаций.
Однако, в том или ином виде описанная ситуация возникает из года в год. Суть всегда одна — условия сильно изменились, и проект не справляется с задачами. Вариации описанной ситуации я встречал и в проектах с двумя разработчиками, и с пятью сотнями, и смог решить проблемы в некоторых из них.
В заметке я пытаюсь объяснить какие именно проблемы решаются методиками, в каких ситуациях процессы будут полезны, а в каких — бессмысленны.
Первым пунктом автор пишет про выручку и ключевые параметры, которые на нее влияют. Если управленцы не сосредоточены на выручке или аудитории — неважно, чем они заняты, какие задачи ставят, и какая будет техническая реализация.
Если для роста продаж зерна надо пахать больше земли — значит, надо пахать, а не описывать, без сомнений. А если надо держать SLA на 5 девяток — надо строить operations и писать процедуры.
1. Опечатка, я про SPoF.
2. Не произвольные, а внутренние корпоративные репозитории.
3. Не так же — сложнее дебажить, нужен мапинг через карту.
4. софизм
5. скрывать результат компиляции хорошо тем, что результат можно будет оптимизировать в байткод, и добавить JIT, а это выведет скорость вычислений на уровень Java и Python
По статье делаю вывод, что Deno — это именно та эволюция ноды, которая стала интересной.
Все аргументы сводятся к тезису «Это неправильная нода, она делает неправильный мед».
Я смотрю с точки зрения enterprise. Как это в Java, Python, Golang, даже в PHP.
1. NPM — это SPF, это просто не проходит по SLA. С прямым импортом удобно делать свой репозиторий. Будет обертка, как composer в PHP.
2. NPM за периметром безопасности, исходящий трафик за фаервол открывать никто не будет. Без вариантов, никаких скачиваний пакетов со стороны при сборке.
3. TypeScript хорош. Никто не хочет писать на JS после Java или Golang, а на TS — вполне.
4. Никого не смущает связь парсера Java с Runtime — это самая популярная в мире платформа. Наоборот, такую связку проще поддерживать, меньше невоспроизводимых багов.
5. Кеширование результата компиляции в файлах или в памяти — детали реализации. Python и Java не страдают.
И так далее. Каждый тезис в этой статье — в пользу Deno.
Тем, что нет ничего. Тупая процедурщина, как в php3. Как 20 лет назад написали fetch в массив — с тем php и похоронят.
Дженерики — то отдельная тема. Хардкодить этого монстра PDOStatement — ошибка дизайна. Надо инъектить в PDO наследника PDOStatement, который бы позволял переопределить fetch.
Полиморфизм? Inversion of Control? Liskov substitution? Нет, не слышали!
PDOStatement просят fetch в объект, а оно возвращает массив. Это ошибка дизайна.
Массив — это процедурное программирование.
Логично вернуть специальный объект типа PdoResultSet, расширяющий SPLFixedArray. Или как в fetchObject, в параметре принимать пользовательский тип для коллекции.
а так-то Феррара их proof of concept написал лет под 10 назад, только тормозят жутко
метод bindParam() — передача констант по ссылке, ниче так для php8? :)
асинхронный режим запросов, который нельзя подцепить к libevent-циклу — зачем он, вообще?
Любую проблему можно решить введением дополнительного уровня абстракции кроме проблемы слишком большого количества уровней абстракции.
Когда нужен тюнинг запросов, например, ничего никто не решает. Абстракции не бесплатные.
PDO предоставляет PDOStatement для запросов, без вариантов. Не переопределить, не расширить.
Почему PDOStatement делает и присваивание параметров, и выполнение запроса, и формирование результата, что за нарушение SRP?
Результат fetchAll() — массив объектов или массивов, без вариантов. А когда нет записей — пустой массив, без вариантов. И зачем он такой, fetchAll() с массивом объектов — что за смесь бульдога с носорогом?
В Yii «model» — мапинг на таблицу, это можно считать слоем персистентности. По терминологии clean architecture это Interface Adapters.
Если для слоя персистентности создать дополнительный уровень абстракции — да, AR надо передавать в него, но я бы не называл это моделями.
Между слоями передаются value object, конечно.
habr.com/ru/company/mobileup/blog/335382
Нарушение IoC у автора — статический вызов. Внедрение чего угодно как зависимости — это и есть IoC ;)
$query = ActiveRecordModel::find(); — это прямое нарушение сразу SRP, OCP и IoC.
Чтобы уйти от связанности кода, надо использовать AR как persistance layer в своих доменных моделях. Композиция — считать AR сервисом персистентности, и передавать его в модели как зависимости.
Для inhouse-разработки смысла в пред-компиляции немного, усложнится SDLC.
Разве что поверх PHP появится аналог Typescript.
PDOStatement не расширить. Убогий синтаксис плейсхолдеров. Коллекции — руками.
А внедрение значения в поля объекта без вызова конструктора при fetch в объект — это ж совершенно непредсказуемое поведение.
SPL types так и остался экспериментальным. SplBool — шикарная же идея, чтобы писать if ($object).
Зачем алгебра в языке для middleware? Зачем делать из скриптового языка компилируемый? Работа с СУБД нужна.
Ответ на вопрос «зачем?» требует описание бизнес-логики. Простите, не могу раскрывать детали конкретных ситуаций.
Однако, в том или ином виде описанная ситуация возникает из года в год. Суть всегда одна — условия сильно изменились, и проект не справляется с задачами. Вариации описанной ситуации я встречал и в проектах с двумя разработчиками, и с пятью сотнями, и смог решить проблемы в некоторых из них.
В заметке я пытаюсь объяснить какие именно проблемы решаются методиками, в каких ситуациях процессы будут полезны, а в каких — бессмысленны.
Если для роста продаж зерна надо пахать больше земли — значит, надо пахать, а не описывать, без сомнений. А если надо держать SLA на 5 девяток — надо строить operations и писать процедуры.
2. Не произвольные, а внутренние корпоративные репозитории.
3. Не так же — сложнее дебажить, нужен мапинг через карту.
4. софизм
5. скрывать результат компиляции хорошо тем, что результат можно будет оптимизировать в байткод, и добавить JIT, а это выведет скорость вычислений на уровень Java и Python
Все аргументы сводятся к тезису «Это неправильная нода, она делает неправильный мед».
Я смотрю с точки зрения enterprise. Как это в Java, Python, Golang, даже в PHP.
1. NPM — это SPF, это просто не проходит по SLA. С прямым импортом удобно делать свой репозиторий. Будет обертка, как composer в PHP.
2. NPM за периметром безопасности, исходящий трафик за фаервол открывать никто не будет. Без вариантов, никаких скачиваний пакетов со стороны при сборке.
3. TypeScript хорош. Никто не хочет писать на JS после Java или Golang, а на TS — вполне.
4. Никого не смущает связь парсера Java с Runtime — это самая популярная в мире платформа. Наоборот, такую связку проще поддерживать, меньше невоспроизводимых багов.
5. Кеширование результата компиляции в файлах или в памяти — детали реализации. Python и Java не страдают.
И так далее. Каждый тезис в этой статье — в пользу Deno.
www.php.net/manual/ru/splfileinfo.getmtime.php
это обертка над filemtime()
Вопрос. Вы clearstatcache() вызываете?
Зачем объявлять функцию last() и временную переменную для решения проблемы со ссылкой в end()?
Смысл однострочника — в отсутствии деклараций: