Спасибо за статью, помогла наконец разобраться что это за зверь такой) По примеру с кешом не очень понятно, получается что если кеш хранит только weakptr, то после того как в него положили значение оно почти сразу удалится оттуда GC, так как указателей то больше нет. Получается это такой кеш, который живет до следующего GC?
Мне кажется выбраны не самые удачные названия. HttpResource конкретно определяет как канал, так и специфику взаимодействия, скрыть за ним не http и правда будет трудоемко.
В этой ситуации подходящим было бы что то типа RemoteResource, с реализациями HttpResource и MessageBrokerResource. Где вся асинхронность оканчивается на уровне адаптера. Да, всех плюшек брокера приложение не получит, но зато скоп изменений будет ограничен адаптером. Если же нужно использовать асинхронность по полной, то, как правильно заметили, нужен редизайн уже за пределами интерфейса.
Суть регулярок в том что они рантайм. Если формат известен на этапе компиляции, то да, всегда есть вариант обойтись без них и написать парсер под конкретную строку. Но если формат определяется во время работы приложения, из каких нибудь прилетающих конфигов, то тут уже сложнее, и нужно динамически строить алгоритм под формат, что и делают регулярки
Там есть возможность в каждый токен добавить мету, указывающую на конкретное «произведение искусства». Можно твит, можно урл, можно хэш от мп3. На что фантазии хватит чтобы утвердить свое право. А токеном в свою очередь владеет уже конкретный человек.
А куда по итогу эти 300к строк кода ушли? Они же там не только жсоны джойнили наверно
Спасибо за статью, помогла наконец разобраться что это за зверь такой)
По примеру с кешом не очень понятно, получается что если кеш хранит только weakptr, то после того как в него положили значение оно почти сразу удалится оттуда GC, так как указателей то больше нет. Получается это такой кеш, который живет до следующего GC?
Мне кажется выбраны не самые удачные названия. HttpResource конкретно определяет как канал, так и специфику взаимодействия, скрыть за ним не http и правда будет трудоемко.
В этой ситуации подходящим было бы что то типа RemoteResource, с реализациями HttpResource и MessageBrokerResource. Где вся асинхронность оканчивается на уровне адаптера. Да, всех плюшек брокера приложение не получит, но зато скоп изменений будет ограничен адаптером. Если же нужно использовать асинхронность по полной, то, как правильно заметили, нужен редизайн уже за пределами интерфейса.
Суть регулярок в том что они рантайм. Если формат известен на этапе компиляции, то да, всегда есть вариант обойтись без них и написать парсер под конкретную строку. Но если формат определяется во время работы приложения, из каких нибудь прилетающих конфигов, то тут уже сложнее, и нужно динамически строить алгоритм под формат, что и делают регулярки