• Laravel Event Projector и концепция порождения событий
    +1
  • Краткий и бодрый обзор архитектуры компиляторов
    0

    Кстати, это можно реализовать обычными регулярками
    /\-\-\[(?P<comment>=+).*?(P=comment)\], а это всё же не полноценный LL\LR парсер, а ограниченная кс-граммтика.

  • Telegram — бот | Полноценное меню
    0

    Эм… везде. Я, пожалуй, просто спрошу: Когда вы в последний раз PSR-1 и PSR-2 открывали и читали?

  • Разрабатывайте плагины для продуктов JetBrains и продавайте их на JetBrains Marketplace
    0

    Ну да, очень дельное замечание. Я и имел ввиду халявные плагины.

  • Разрабатывайте плагины для продуктов JetBrains и продавайте их на JetBrains Marketplace
    0

    У меня есть смутные подозрения, что OS лицензия как раз про такие вещи (включая). И разработчики плагинов вполне могут претендовать на неё.

  • Larabeer Moscow — 21 июня
    0

    Это моя вина, не успел нормально прогнать его и понять где можно улучшить. =(

  • Larabeer Moscow — 21 июня
    0

    Я был бы не против пересмотреть в формате записи (Adelf там записалось норм?), а то есть подозрения что много чего упустил.

  • Я сделал PWA и выложил в трёх магазинах приложений. И вот что я выяснил
    0

    Не ASM, с C++.

  • «Мобильный контент» бесплатно, без смс и регистраций. Подробности мошенничества от Мегафона
    +2

    Теле2 тоже начали так же себя вести. Буквально месяц-два назад началось. Пополняешь баланс (не важно откуда, хоть из личного кабинета) и летят смс со спамом. При этом в договоре явно ставил галочку с отказом от подобных вещей.


    Кажется альтернативы кончились. Начинаю потихоньку задумываться об отказе вообще от телефона. =\

  • PHP в 2019: лучше, чем вы о нём думаете
    0
    Могу согласится, что пхп всего ненамного медленнее

    Эээ… Либо я слепой и в тестах, кажется, всё чуть-чуть наоборот? Или я просто сарказма не понял?


    P.S. Ходят слухи, что uv побыстрее libevent будет. Но это только слухи.

  • PHP в 2019: лучше, чем вы о нём думаете
    0
    Неблокирующий ввод-вывод и обработка запросов без убийства стейта — разные вещи, друг от друга особо не зависящие.

    Почему? Работа без убийства стейта практически бессмысленна при наличии блокирующих операций, иначе 2+ запрос будет спотыкаться об них и в результате получится ещё хуже.


    … ну если только не форкаться или не стартовать в несколько параллельных процессов с разгребанием по ним запросов балансером.


    И неблокирующие сокеты в PHP есть, емнип, со времён PHP3 из коробки. А значит все или почти все операции с ФС доступны в неблокирующие режиме. Обёрток удобных нет, но сами операции есть.

    Хм, через file:///?

  • PHP в 2019: лучше, чем вы о нём думаете
    0
    Я как и Volch так и не понял откуда возьмется разница при выполнении запроса, если так или иначе мне нужно дождаться получения данных.

    Эээ… Ну так fcgi каждый раз стартует и интерпретирует php, а работая в эвентлупе этого не потребуется. Более того, можно один раз весь стейт инициализировать, а запросы обрабатывать мелкими хендлерами. Получаем то, что 80-90% кода на PHP просто выполнится один единственный раз за всю жизнь сервера, а не каждый раз.


    А отсыл к PDO и mysqli опять же только подтверждает мое утверждение что проблема не в PHP как языке, а конкретных библиотеках и фрэймворках для него написанных.

    Отсыл к PDO как раз и касается того, что в таком режиме работы проблема блокирующих операций — единственная остающаяся.


    На счёт библиотек и фреймов… И да и нет. Всё же функции работы с файловой системой, например, являются частью stdlib языка. А они блокирующие.

  • PHP в 2019: лучше, чем вы о нём думаете
    0

    Пользователь как раз не особо увидит разницу между 5мс и 15мс.


    А в противном случае никто не мешает работать в эвентлупе, а в БД ходить не через PDO, а через, например, mysqli (там есть асинхронные запросы). И в результате получим всё то же самое, что и в Go:


    Заголовок спойлера

    image


    Только этим никто особо не занимается, т.к. подобные копейки редко кому нужны на практике.

  • PHP в 2019: лучше, чем вы о нём думаете
    0
    Вот если вас не затруднит на одной и той же локалке, сделайте тест который будет делать SELECT * FROM users WHER id=1 и выплевывать результат в простейшем виде. Почему-то мне кажется что не будет Go вариант сильно быстрее.

    Как раз наоборот. Все тормоза в скорости работы PHP как раз из-за блокирующих операций.


    Т.е. при сравнении "hello world" на Go и PHP скорость будет ± идентичная (благо на дворе 2019ый и PHP на синтетике не уступает gcc -o2), а вот когда появляются "блокирующие" операции, то:


    1) В Go самым логичным вариантом является не писать такой код, т.к. он зафризит вообще всё. Ну и плюс горутины (которые вообще в другом треде висят) никто не отменял.


    2) А для PHP в большинстве случаев это вообще не является проблемой, т.к. в современном мире он масштабируется процессами, а не тредами. Т.е. удобство использования и лаконичность было изначально в приоритете, нежели скорость. И любая операция в PHP, которая обращается к внешним ресурсам "под капотом" содержит что-то вроде: while (!result) { usleep.. }

  • PHP в 2019: лучше, чем вы о нём думаете
    +2

    А она, извиняюсь, зачем? Ну хоть одну причину сможете назвать?

  • Новое в PHP 7.4
    +3
    Подскажите какой именно функционал недоступен в PDO, но доступен в php_mysqli?

    Асинхронные и неблокирующие запросы

  • Новое в PHP 7.4
    0
    Начерта мне шаблонизаторы, если похапэ сам по себе — отличный шаблонизатор?

    Ну, скажем так, современные шаблонизаторы — это не только вывод с экранированием. И там нативному PHP до них как до луны.


    Но я допускаю, что возможно из-за того, что вообще не помню когда последний раз писал echo не совсем объективен в этом плане.


    поломка обратной совместимости в минорной версии

    Мы все прекрасно знаем какие у PHP "минорные версии"))) Такой же php 5.2 -> 5.3, например, вообще полностью изменил язык в своё время.


    джависты вон дженерики поломали

    Джависты себе давно язык сломали (пользуясь случаем) =)


    Тем более, когда это ломает 12 из топовых 1000 пакетов, причём ломает не на уровне "в такой ситуации возникнет баг", а на уровне "вообще не запускается"

    Ну вообще это ССЗБ. Смотря на такой код: https://github.com/symfony/messenger/blob/4.1/DependencyInjection/MessengerPass.php#L118 Мне рыдать хочется. Блин, неужели так сложно разрабам скобки расставить было? А ещё пишут что в симфони норм код...


    У меня нет, короче, контраргументов =) Ну убили совместимость, да, но как раз в тех местах за которые надо писателей на костёр отправлять.

  • Новое в PHP 7.4
    +1
    Что идёт дальше — я не понял умора. Зачем-то выпилили <?, хотя это очень даже удобно

    Он не нужен, очевидно и доставляет в разы больше проблем, нежели профита. Да и им пользуются лишь совсем новички. Покажите хоть один пакет в композере, где он используется?


    Для шаблонов удобно и красиво. Было.

    Для шаблонов есть шаблонизаторы.


    Менять приоритет операторов — это гениальный ход. Народ-то думал, что синтаксические косяки придётся тащить во имя обратной совместимости, но разрабы PHP были полны решимости.

    Рекомендую почитать пост и понять что поменяли. Сейчас это выглядит как "не читал, не понимаю что делают, но осуждаю". Я не представляю себе ни одной задачи, где бы текущий приоритет операторов решал какую-либо задачу, так что при использовании конкатенации использование скобок — дефолтное решение, а как следствие — никаких поломок обратной совместимости.


    а повсеместно нужный тернарный оператор запретили

    Тоже самое что и выше: "Не читал, но осуждаю". Никто не запрещал тернарных операторов. Запретили говнокод в тернарниках.

  • Новое в PHP 7.4
    0

    del (промахнулся веткой)

  • Новое в PHP 7.4
    0
    Печально, но видимо на то были причины

    Вот тут подробнее про эти самые причины: https://www.youtube.com/watch?v=teKnckg5x7I

  • Новое в PHP 7.4
    +1
    array_map(fn($item) => '№' . $item, [1, 2, 3])
  • Новое в PHP 7.4
    +1

    Реализация LSP для типов.

  • Новое в PHP 7.4
    +2

    Он и так сейчас выключен по умолчанию, уже больше пяти лет как. Но вы же видите ситуацию, выше в комментах люди даже не догадываются почему его удаляют, а на тостере полным-полно вопросов "почему гружу на продакшн и не работает".

  • Новое в PHP 7.4
    +2

    Настраивать целый интерпретатор под один единственный проект и каждый раз мучать админов для перенастройки, если что пойдёт не так — это само по себе извращение.

  • Новое в PHP 7.4
    +1

    Потому что он настраивается на уровне php.ini и как следствие — глобален на все проекты на сервере сразу (давайте временно забудем про докер и прочие штуки и возьмём в качестве примера типичный VPS прод или шаред).


    Так что либо придётся прописывать opcache.preload=/home/username/site.org/vendor/preload.php
    под один единственный проект. И при появлении site-2.org уже ничего с этим не сделать.


    Либо делать тоже самое на уровне fpm конфигов в виде php_flag[opcache.preload]=xxx. Что примерно тоже самое, но получше, т.к. можно отдельно воркеры под каждый ресурс запилить.

  • Новое в PHP 7.4
    0
    Насчет интерфейса внешних функций например на C я не понял этот код будет налету компилироваться всякий раз или только при первом запуске или еще как?

    Зависит от настроек в php.ini. По умолчанию FFI доступен только в файлах, которые загружаются с помощью preload функционала (файлы для которого, напоминаю, тоже указываются в ini конфигах).


    Пруфы:
    1) ffi https://github.com/php/php-src/blob/master/php.ini-production#L1892
    2) preload https://github.com/php/php-src/blob/master/php.ini-production#L1854


    UPD: Персональное ИМХО по этому всему: Функционал с прелоадом и ffi будет очень слабо востребован в связи с тем, что его почти невозможно нормально использовать.

  • Как быстро попробовать CQRS/ES в Laravel или пишем банк на PHP
    0

    // del, перепутал 100 и 1000 rps

  • PHP-Дайджест № 156 (6 – 20 мая 2019)
    +3

    К сожалению, слоников надо было заказывать за несколько месяцев до начала конфы. Мы там по срокам просто не успевали сделать всё в таком количестве. На следующей уже будет, теперь опытные =)

  • Краткий и бодрый обзор архитектуры компиляторов
    0
    На PHP я реализовал токенайзер на генераторах и два прохода по сути идут параллельно :)

    Тут есть несколько проблем:


    1. Нормальный (по скорости) лексер на пыхе возможен только с использованием preg_match_all/preg_replace_callback, т.е. с полным анализом всего и сразу.
    2. Даже если написать вручную это дело или используя preg_match, то нужен буфер для всяких lookahead в парсере.

    А ещё я бы попросил ссылочкой на гитхаб в меня покидаться, не отказался бы посмотреть на это дело, можно?)

  • Асинхронный PHP и история одного велосипеда
    +3

    Мне удобнее писать:


    $user = yield $account->findUserByEmail($email);
    
    try {
        yield $this->validateUserDoesNotExist($user);
        yield $this->createUser($email, $password);
        yield $this->sendRegistrationEmail($email, $password);
        yield $this->sendAckSuccess(true, $callback);
    } catch (\Throwable $e) {
        // ...
    }
    

    И автокомлит будет, и статический анализ, и меньше лишних then/otherwise

  • Асинхронный PHP и история одного велосипеда
    +2
    А в чем проблема?

    В этом примере? Огромное количество лишнего и ненужного кода, например =)

  • PSR-14 — главное событие в PHP
    0

    В случае psr-3 берётся LoggerInterface и без каких-либо изменений всовывается в любой фреймворк. Это как раз публичный интерфейс, который можно запросто дёргать и напрямую без всяких обвязок и подмена реализации на другую ничего не изменит. Миддлвари имеют примерно такую же цель. Про этот интерфейс разработчик знает и активно может использовать.


    А вот EventDispatcherInterface — это внутренняя и частная реализация диспатчера, которая никуда не торчит. Что мы потеряем если вообще удалим этот интерфейс? Какую переносимость потеряем и что не сможем сделать?

  • PSR-14 — главное событие в PHP
    0

    Совместимость компонентов фреймворков? Это чтобы использовать ListenerProviderInterface из зенда и подсовывать его в EventDispatcherInterface из ларки? Именно для таких задач этот провайдер существует?


    Ну… Это не то что странно… Это вряд ли вообще кому-то вообще нужно, скажем так.

  • PSR-14 — главное событие в PHP
    0
    Основные училия сейчас направленны на ФФИ. Лично меня они радуют. Должы и Вас. Потому что можно будет писать свой новый ПХП по верх стандартного.

    Это вы про бесподобный пост от ircmaxell?

  • PSR-14 — главное событие в PHP
    0

    Когда буду алгебраические типы, тогда можно будет. Мои попытки написать RFC на эту тему закончились тем, что их внедрение потребует дохрена всего. Очевидно, что подобные вещи надо внедрять постепенно и ковариантные тайпхинты вполне себе первый шажок в этом направлении.

  • Чудеса упаковки от Microsoft: ядро Linux в Windows 10 и движок IE внутри Chromium Edge
    0

    Так иксы вроде уже закопали (ну или пытаются), а на замену идёт wayland.

  • PSR-14 — главное событие в PHP
    0

    del (задублировалось)

  • PSR-14 — главное событие в PHP
    0

    С таким же успехом, перефразируя, можно спросить про то, зачем ему знать об объекте, ведь событием может быть и массив, и строка… Не правда ли? Zend и Laravel тому в пример.


    P.S. Но с другой стороны понятна причина добавления тайпхинта, т.к. есть вот такой RFC: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters Позволяющий сузить область при наследовании и указать конкретный тип. Но… Но мы возвращаемся к первому моему примеру с EventInterface, чем он в таком случае не угодил? Пусть даже с пустой реализацией, но мы сразу же выкинем из под категории "событие" весь stdlib php и все вендорные классы, которые не являются потомками EventInterface

  • PSR-14 — главное событие в PHP
    0

    Да, я вижу что в dispatch можно передать что угодно, хоть stdClass… Но если это допустимо, то почему нельзя передать строчку? Или массив? Если не делать ограничений на типы объекта, то почему нужно ограничивать объектом? Ну ладно, опустим этот момент.


    А теперь главный вопрос: Вот вы совершенно правильно говорите, что идентификатор должен детектить провайдер, который используется внутри диспетчера. А нахрена в PSR нужен интерфейс провайдера, который является частным случаем реализации диспатчера, должен использоваться только внутри него и совершенно не пригоден для использования вне? PSR как бы про публичные интерфейс, которые дёргаются внутри пользовательских приложений.

  • PSR-14 — главное событие в PHP
    0
    Видимо решили так сделать, чтобы диспатчер и/или листенеры могли отличать экземпляры событий одного класса, по event type или event source еще как-то, хз, в зависимости уже от конкретной реализации.

    Для этого и у Zend, и у Laravel, и у Symfony и, наверняка, ещё у кучи других есть имя события. Так что можно было бы сделать запросто вот так:


    interface EventInterface
    {
        public function getName(): string;
    }
    
    interface EventDispatcherInterface
    {
        public function dispatch(EventInterface $event);
    }
    
    interface ListenerProviderInterface
    {
        public function getListeners(string $name): iterable;
    }