Несмеянов Кирилл
@SerafimArts
Руководитель Отдела Сокрытия Раскрытых Рептилоидов
Information
- Rating
- 2,675-th
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Руководитель Отдела Сокрытия Раскрытых Рептилоидов
Information
Есть подозрение, что в качестве "малоизвестной БД" используется обычная монга, минусы и тормоза которой довольно известны.
Не совсем. Ещё третий шаг - рантайм. Когда сам байткод выполняется на JVM.
P.S. Сейчас можно просто скипуть все этапы и за один шаг сразу начать выполнять код сразу из сырцов, без компиляции (ну точнее оно остаётся всё, подозреваю, просто автоматом всё).
Нишу JSP нынче осваивает шарп с блейзором, а я про другое немного.
PHP по принципу своей работы вначале из сырцов компилится в опкод/байткод, потом запускается и по-дороге ещё в машинный собирается где можно (ака JIT). И всё это командой
php path/to/Source.php
.Вот на это я и намекнул, что вместо javac + java получаем один java, который делает всё это вместе как пых.
Вот так Java медленно превращается... медленно превращается... в PHP =)
Насколько я понимаю -- сама статья и подобная подводка появилась просто потому, что человек впервые увидел конструкцию, которая не похожа на типичные while/if/for/do/etc. Это вполне типично и нормально для любого джуниора, ничего страшного в этом нет.
Однако, хочу заметить почему такая реакция сообщества:
Во-первых, генераторы предназначены для совершенно иных вещей. Код можно ещё ускорить и улучшить избавившись от них.
Во-вторых, есть файберы, которые позволят сделать тоже самое, но намного удобнее.
В-третьих, есть delcare ticks, которые позволят творить ещё большую магию. Удивления тут будет ещё больше.
Если нужно ещё больше наркомании, то можно ознакомиться с FFI и делать паузы в выполнении функции напрямую отправляя команды в VM. Тут глаза у вчерашнего джуниора вообще могут на лоб вылезти.
О, а ещё можно это сделать через создание нового потока или подпроцесса, и работу через SysV очереди или сигналы. Тут ещё больше наркоты всякой можно запилить.
Да дофига как это можно сделать, хотя бы стрим враппер написать, который будет налету патчить исходный код, вычислять всё заранее и сразу же компилировать (т.е. вшивать внутрь) результат выполнения подобной чистой функции. И в таком случае, например, не то что никакого стека не будет, но и вообще какого-либо вызова.
P.P.S. Реально получилась бы прикольная статья про инлайнинг подобного вычисления. А уж особенно, если это как-то решалось бы через VM, как это сейчас делается для strlen, is_null и других функций.
Ну т.е. я к тому веду, что:
А) Вариантов снаркоманить подобный финт ушами -- тысячи.
Б) И генераторы тут не то что не нужны, а просто лишние, если задача поставлена именно так.
P.S. Ну и тимлид -- это всё же больше полу-менеджерская полу-разработческая позиция и на такой позиции не обязательно знать всё подряд, задача -- принимать решения что делать и кому делать исходя из вводных данных. Любая позиция сеньора требует на порядки больше технических знаний и умений. Так что тимлидам можно даже код не знать как писать... в теории, конечно)
А while -- это синтаксический сахар для goto. Шах и мат, шахматисты! =)
Генераторы в первую очередь нужны всё же для реализации кооперативной многозадачности, что в современном мире красиво решается с помощью файберов (ака грин тредов) или каких-нибудь свуловских корутин.
А не то что вы там приводили в примере. Благо, как вам уже раза 3-4 (если не больше) написали - код ещё больше можно оптимизировать и ускорить просто избавившись от этих самых генераторов. К слову, рекурсия, подозреваю, тоже будет быстрее (но не в вашем коде, кажется) за счёт хвостовой оптимизации (а я даже и не помню, есть ли она в пыхе?).
А с чего вдруг синтаксическая конструкция, которая есть в JS, TS, C#, Go, Rust, Java, Kotlin, Scala, Haxe, <подставь любой язык> навеяны, внезапно, именно доктриновскими аннотациями?)
А, ну значит не правильно вас понял. Просто там было "очень давно не видел чтобы кто-то использовал суперглобальный массив $_ENV", вот я как бы и удивился, т.к. параметры окружения нынче уже мейнстримом стали вообще для всего, как и сам дотенв.
Так здрасть, наоборот же сейчас всё через дотенв идёт, который шарит всё в энв, а потом уже из энва в конфиги попадает.
Потом:
А уже потом:
А так да, в целом согласен, код времён PHP 4/5. Сейчас так уже почти не пишут, только разве что начинающие.
Не знаю почему статью заминусили, т.к. изложены вполне здравые, пусть и довольно очевидные околофилосовские размышления и выводы.
Лично мне понравилось, т.к. с течением времени начинаешь забывать этот небольшой нюанс про "возврат управления", работая с высокоуровневыми языками, где помимо
return
ещё километр всякихyield
, иsuspend
. На практике -- совершенно бессмысленно, а просто как интересная "ремарка на тему" -- вполне себе норм.Давным-давно весь интернет перерыл в поисках аналога UE.
Когда на входе (в конфиге или ещё как) есть строготипизированные структуры/события вроде:
UserCreated out { time: int, id: int<1, max> }
, есть условия и какие-то другие экторы, вродеMailSend in { xxx, text: string } out { status: bool }
. Потом в списке их выбираешь и строишь схему, а результат можно сгрузить в yaml/json/xml.Без всяких SQL и прочего, просто DTO и функции, оперирующие ими в каком-либо xml/json/yaml/etc формате, т.к. их проще всего из кода существующего выгрузить.
Из похожего нашлась только камунда, которая позволяет подняться в докере, считать и выгрузить xml. Близко, но не совсем то.
Увидел статью, обрадовался, прочитал, расстроился, выглядит как опять что-то совсем не то что нужно и опять очередной BPMN, а не простой редактор воркфлоу. Причём ещё и cloud, а не с возможностью развернуть локально в докере тупо как админку для файликов =(
Пыщ https://wiki.php.net/rfc/new_without_parentheses
P.S.
Напоминаю, что сейчас 2024ый год =)
P.P.S. Спасибо тому, кто сделал это "новый" и "ультра крутой" редактор комментариев. Хочу взглянуть ему в глаза...
Стоит разделять типы и тайп-хинты. Это разные вещи. Типы определены на уровне переменной, а тайп-хинты проверяют тип на совпадение. И разделять типы в php следует именно по этим критериям.
В список типов PHP входят:
bool
,float
,int
,string
,null
,object
,resource
,array
. Если мы учитываем внутренности языка (специфичные типы для VM), то ещё:undef
,false
,true
,reference
,const
.А в список тайп-хинтов, помимо указанного списка, следует так же добавить
true
,false
,parent
,static
,self
и композицию из юнион и интерсекшн типов.Причём тут в списке вообще enum, тем более в "специальных типах" вообще не понятно, т.к. это обычный объект.
Опять мимо. Очевидно что строгая статическая или динамическая типизация уровня контрактов, а слабая динамическая только на уровне локального контекста.
А где про типы полей классов и типы констант в ответе?
Сессии в PHP работают так, как определено в SessionHandler. То что по умолчанию они пишутся в директорию, это так. Но это не означает что это везде и всюду так. Более того, на любом проекте, где больше полутора калек - это скорее наоборот, совершенно не так. А на проектах где больше одного сервера - при использовании файлов мы получаем замечательные баги)
А ещё, повторное включение через
_once
вернётtrue
, а не результат работы файла.Так если анонимная функция не использует переменные из локального окружения, то с чего это ей быть замыканием? Тоже самое и про use, если его убрать, то с чего это такая функция будет замыканием?)
Ну и где тут в PHP
use
?)Ну тут вообще дичь написана. Определение "связывания" означает прикрепление типа/ссылки к переменной. Определение "позднее" означает, что ссылаться переменная на кого-либо будет в рантайме, в отличие от "раннего", когда связывание происходит на этапе компиляции.
Позднее связывание в PHP (когда тип выводится в рантайме), если мы говорим про ссылки на классы, применяется в
$this
,static
и некоторых случаяхself
(когда self определён в трейте или анонимной функции)....
А ещё не стоит забывать, что в вебе нет MVC и его реализовать практически невозможно)))
Так доктрина как раз и берёт текущие сущности/модели, делает дифф с состоянием базы и на выходе выдаёт миграцию со всеми отличиями.
А не проще ли в таком случае использовать доктрину? Потому что пока что выглядит как изобретение велосипеда, но только переусложнённого.
Думаю это дело привычки. Ориентироваться в иерархии в любом случае в варианте от SCSS попроще будет.
Что в свою очередь разворачивается в:
Контекст моей "претензии" был в сторону того, что статья позиционируется как "используем генераторы", но ни слова про то, что основная задача генераторов - это ставить выполнение функции на паузу для переключения контекста исполнения на выполнение других процессов.
А не то, что "инструмент выбран не правильно" ;)
Да, он экономит память, но это лишь побочный эффект того, что в коде не используются массивы в которых хранятся все данные выборки.
P.S. Оригинальная реализация с `while($cursor->getNext()) {}` работает ровно по такому же принципу - не создаёт массив, а каждый раз возвращает новые данные. Вот альтернативный пример как это можно делать, экономя память, вместо генераторов.