Коллега, подскажите пожалуйста: у меня один микросервис, немного нагружен но в то же время очень простой. Сначала была обычная реализация на PHP, но так как мне надо данные хранить прямо в переменных, и иметь к ним доступ из любого запроса (то есть все запросы надо обрабатывать в одном потоке), то я у было решил переписать все на Swoole, но в процессе отказался от Swoole в пользу NodeJS, так как Swoole запускает фоновые процессы (таймеры) в отдельном потоке (где у меня уже нет доступа к тем переменним, которые я использую при обработке HTTP запросов). На NodeJS же все сейчас работает отлично, setTimeout или setInterval работают в том же потоке, что и HTTP сервер (и соответственно имеют доступ ко всем тем же переменным что и сервер). Но тем не менее мне не дает покоя мысль о том, что я мог что то упустить, и возможно Swoole все таки позволяет как то запускать таймеры в том же потоке что и http сервер, или все же нет такой возможности? SwooleTable не вариант, нужно использовать именно одну и ту же переменную и сервером, и таймерами. Заранее благодарю!
Тут вас поддержу, мне также больше нравиться подход Java к работе со строками (поэтому к стати так и написал про String::contains, ведь в Java оно так и реализовано — someStringObj.contains(...)). Касательно того что String являться ключевым словом (как и Array к сожалению) вы также правы, нет смысла наверно в таком случае мечтать о таких класах как String и Array, которые могли бы вобрать в себе необходимый функционал, ваш подход хотя бы предлагает реальное решение в текущей ситуации. Но может все таки в будущем кто нибудь найдет способ подшаманить ядро, чтобы в зависимости от регистра был базовой тип string, а слово String не было ключевым…
А зачем выделять базовые функции в отдельный неймспейс? Пусть в главном будут, они же БАЗОВЫЕ. Ну и StringUtilities как то странно смотриться, можно же просто String, тоесть:
<?php
String::contains('apple', 'e');
// или с другого неймспейса
\String::contains('apple', 'e');
А вот за compareUsingNaturalOrder вместо strnatcmp плюсую, однозначно надо так делать!
Например аннотации. Да, я читал что такому решению предшетвовали исследования и это лучший из имеющихся вариантов, но как говориться «серцу не прикажеш» =). Есть и другие мелочи, например "??=" вместо ожидаемого мной "?=" (не знаю есть ли такое вообще в других языках, просто почему то думал что так будет логично на ряду с "+=" и другими).
Будет ENUM, наконец то! Только вот уже страшно, опыт реализации прошлых фич шепчет что опять какую то дичь придумают «чтобы не как в C/JAVA» =) Посмотрим…
Что ж, возможно просто мои знания ограничены. Попрошу тогда помочь мне разобраться: создавая сегодня сайт, зачем делать его адрес с www? Каков use case?
Согласен полностью, от них никакой пользы. Для меня как для разработчика инструментов для анализа веб сайтов эти www постоянно создают кучу проблем. Давно уже все сайты надо делать исключительно без www. А несогласные только те, кому лень перенастраивать свои старые проекты.
В новом P++ можно будет реализовать массу революционных улучшений, очистить от легаси, и навести порядок не думая об обратной совместимости
Ну наконец-то! Я думаю всем языкам со временем так надо делать (например каждые 20 лет), ато из-за проблем обратной совместимости, с годами накапливается просто куча мусора в кодовой базе, от которого никак не избавиться.
Ну или как сказал коллега выше, не поддерживать обратную совместимость в каждой новой мажорной версии.
Братан, ты не одинок! Я уже более 5 лет работаю программистом, и все еще хожу со старой звонилкой! И да, когда он сломаеться, тоже наверное куплю себе смартфон (что то маленькое и мощьное, возможно Sony Xperia XZ2 Compact). Но кто знает сколько еще лет пройдет к тому времени =)
А вот за compareUsingNaturalOrder вместо strnatcmp плюсую, однозначно надо так делать!
Согласен полностью, от них никакой пользы. Для меня как для разработчика инструментов для анализа веб сайтов эти www постоянно создают кучу проблем. Давно уже все сайты надо делать исключительно без www. А несогласные только те, кому лень перенастраивать свои старые проекты.
Ну наконец-то! Я думаю всем языкам со временем так надо делать (например каждые 20 лет), ато из-за проблем обратной совместимости, с годами накапливается просто куча мусора в кодовой базе, от которого никак не избавиться.
Ну или как сказал коллега выше, не поддерживать обратную совместимость в каждой новой мажорной версии.