Мне сложно понимать написанное в законах
Если хотите сами идентифицировать пользователей, то вам придется стать оператором ПДн.
Ну да, только вот все эти дни, пока я тут не был, писал разрабам платных движков и что же выходит?
У нас нет полностью функционала
ООП сейчас основная производственная парадигма
Мнение большинства - всегда ошибочно, ибо большинство людей...
Вообще ООП-шный код даже на незнакомом языке зачастую выглядит вполне понятным.
Если бы все было так просто, но синтетические тесты мало информативны на практике.
Это запросы к php или статика тоже?
Не поверю, что веб-сервер на php отдает статику быстрее nginx.
А если у нас сайт, то там большая часть это статика.
Ок, допустим это api, и все запросы к php, "50 000 запросов в секунду" - это 20мкс на запрос, "4 500 запросов в секунду" - это 222мкс на запрос.
За сколько у нас отрабатывает api-запрос, не беря тяжелое и совсем легкое, в среднем 50-100мс.
И это мы еще не тестировали как себя поведет php-шный вебсервер при реальных запросах, где работа с базой, ошибки, а иногда и фатальные и т.д. К примеру, fpm очень хорошо шарит память между своими процессами, а на сколько хорошо workerman это делает?
1. OpenCart
2. WooCommerce
объекты не в вакууме существуют, их чтото создает и передает необходимые данные
А нужно передавать buffer, т.е. сырые данные запроса http.
В Workerman гдето есть код по созданию объекта класса Request, и есть вызов onMessage с передачей туда Request.
Обработка http-запросов демоном на php скорее всего будет менее производительно чем через php-fpm
Зря, не разберетесь с ООП, дальше не сможете продвигаться.
Так у вас уже создан экземпляр класса, Workerman его создал. Весь смысл ООП, что вам не нужно вникать, что и как там делал Workerman - вам не нужно самому парсить запрос http, у вас есть есть готовый объект Request, с набором функций-методов, для удобного получения различных параметров запроса.
зачем взяли этот проект?
Для изучения ООП можно что-нибудь по проще, тем более что Workerman хреново написан и по нему не стоит изучать ООП.
роутер от какого-нибудь фреймворка или пакета?
что пробрасывается buffer можно найти по ProtocolInterface::decode, например
не понимаю зачем, куда, когда..
или сохранить в переменную
Это уже пошли выкрутасы. Вы сами высказали, что мое мнение не авторитетное. Поэтому уточнил, что это не только мое мнение.
Вот только он против современного так называемого ООП. Его слова: "Я придумал термин ООП, но не имел ввиду C++". Есть еще его высказывания подобной направленности.
И чем же ФП сложное? С любой стороны ФП проще. Потому что Лямбда-исчисление само по себе простая модель. Может ли быть полноценный удобный язык проще чем Лисп? Идея о том, что приложение это просто функция - простая. Даже такие сложные приложения как компиляторы/интерпретаторы прекрасно реализуются в таком стиле. Можно легко разложить такое приложение на функции и держать все это в голове. Подобное приложение в стиле современного ООП будет монструозным и запутанным, его невозможно будет держать в голове.
Человек - не машина. Инструкции не любят читать и плохо понимают. Потому что императивность. Декларативный язык математики понимают намного большее количество людей. Только не надо цепляться за слова и утверждать, что ООП концептуально не является императивной моделью. ООП всё то же последовательное изменение состояний, только в другом виде.
Это не означает, что идея не дурацкая. Повсеместно - значит используется большинством. Большинство - всегда ошибочно, потому что нет своего мнения, потому что толпа, у толпы нет интеллекта. Все побежали и я побежал. Самые лучшие идеи всегда не находятся на поверхности.