И интероп с жсом только через примитивы => а это строки и eval

И интероп с жсом только через примитивы => а это строки и eval

в прочем ничем не отличается от getType в рантайме)

в прочем ничем не отличается от getType в рантайме)

Чем тебе GetType не угодило?)

Ну типа инфраструктурная штуковина для инфраструктурных штуковин. Нормальный такой, полноценный рефлекшон.

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

что бы невилировать недостаток информации о типах

ну и да - мне c# как язык хоть и нравится, но все же мне кажется что мы ниочем говорим просто. Потому удачи, и я все

ну и да - мне c# как язык хоть и нравится, но все же мне кажется что мы ниочем говорим просто. Потому удачи, и я все

Хороших выходных)

Я когда то давно учил тайпскрипт и запомнил что эта штука сугубо рантайм. А интерфейсы там компайл-тайм. Всё. Не юзал. Не юзаю. Не планирую юзать.

Так норм

Зачем типы в рантайме?

Зачем типы в рантайме?

Для инфраструктурных штук. Например, берёшь класс, достаёшь информацию о типе, оттуда достаёшь информацию о реализуемых интерфейсах и регистрируешь в IoC контейнере данный класс как реализацию всех этих интерфейсов. Или мой случай. Я обработчики команд и запросов помечаю всякими разными интересными атрибутами, например [RunInTransaction], и если у обработчика стоит данный атрибут - я автоматом прикручиваю ему декоратор, который заверенёт его вызов в транзакцию. Банально меньше кода ведь писать))

Товарищи, есть ли нормальный способ пропатчить (как HTTP PATCH) DTO в статическом языке? Как это правильно написать?

вот я читаю вас и думаю как обойтись без instanceof но судя по всему никак

надо бы удалить instanceof из языка ;)

ок, если удалим - как тогда

можно даже подобие утиной типизации делать и по содержимому понимать что за сущность пришла, но это хрень

и вообще патчить DTO хз, я думал они неизменяемые. типа если тебе нужно что-то изменить то делай новый DTO

ок, если удалим - как тогда

я не читал тред) ща поищу начало

или декорируй его, кстати

или декорируй его, кстати

чорт, это офигенно

ну вот варик)

единственное что, если декорировать декорированный, то количество данных в памяти будет расти

допустим, по сети постоянно приходят патчи

ну типа у тебя рест и прям пач приходит прям хттпшный

единственное что, если декорировать декорированный, то количество данных в памяти будет расти

а ты копии не создавай и все норм будет

допустим, каждую секунду приходит патч для одного и того же объекта

неиспользуемые поля утекут

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

короче, приблизительное решение: interface Item { // properties } class InMemoryItem { constructor(property values) constructor(copyFrom: Item) } class PatchedItem(private val patch: Json, private val fallback: Item)

или декорируй его, кстати

прошу прощения что влез, объясните глупому что здесь подразумевается?

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

Вопрос больше теоретический и даже не мой. Я представляю себе мобильное приложение, которому по вебсокетам прилетают патчи.

прошу прощения что влез, объясните глупому что здесь подразумевается?

паттерн Decorator

прошу прощения что влез, объясните глупому что здесь подразумевается?

вот прям в вики кину ссыль, не серчай - https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BA%D0%BE%D1%80%D0%B0%D1%82%D0%BE%D1%80_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

короче вместо наследования используешь композицию

и ассоциациями включаешь в объект то чего ему не хватает в каком-то кейсе

по ссылке, по значению.... это уж как язык позволяет и как там принято

понял благодарю

нзчт

короче, приблизительное решение: interface Item { // properties } class InMemoryItem { constructor(property values) constructor(copyFrom: Item) } class PatchedItem(private val patch: Json, private val fallback: Item)

чот как-то не очень выглядит

короче, приблизительное решение: interface Item { // properties } class InMemoryItem { constructor(property values) constructor(copyFrom: Item) } class PatchedItem(private val patch: Json, private val fallback: Item)

ну впринципе это первое что приходит в голову, блин тут тестами все покрывать придется, много логики получается, или не прав?

а у вас там что, конструктор можно перегрузить?о_О

ну впринципе это первое что приходит в голову, блин тут тестами все покрывать придется, много логики получается, или не прав?

+

а у вас там что, конструктор можно перегрузить?о_О

Пример на Kotlin, можно кучу конструкторов, как и в Java.

Пример на Kotlin, можно кучу конструкторов, как и в Java.

зависть

зависть

А где нет?

JS))

там другие техники

блин просто если ты в такую гибкость начинаешь уходить ты рано или поздно задумаешься о reflection, а когда это уже начинается - начинается полный ад

я перерос reflection и делаю всё, чтобы этого не допустить)

я прост в свое время что-то делал на рефлексиях в пыхе и оно превратилось в метафизическое непонятное нечто

рефлекшн использую только как костыль чтобы исправить косяки библиотек, код которых мне недоступен

код шредингера епт)

блин просто если ты в такую гибкость начинаешь уходить ты рано или поздно задумаешься о reflection, а когда это уже начинается - начинается полный ад

соблазн часто у меня по крайней мере есть

ребят спасибо большое за помощь всем хорошего дня

короче, приблизительное решение: interface Item { // properties } class InMemoryItem { constructor(property values) constructor(copyFrom: Item) } class PatchedItem(private val patch: Json, private val fallback: Item)

скажи еще раз, у тебя какая цель?

я прост в свое время что-то делал на рефлексиях в пыхе и оно превратилось в метафизическое непонятное нечто

А зачем пыхе рефлексия? Он же динамический, $obj->$anyField

скажи еще раз, у тебя какая цель?

получать пропатченный объект

А зачем пыхе рефлексия? Он же динамический, $obj->$anyField

ччтоб изваращаться и получать код гибкий как сопли

я прост в свое время что-то делал на рефлексиях в пыхе и оно превратилось в метафизическое непонятное нечто

тащемта в динамических языках объекты мало чем отличаются от хэш-таблиц, с которыми можно делать вообще всё что угодно $original = new SomeObj(); $patch = clone $original; $patch->$patchedField = $patchValue;

тебе объекты твои в рантайме нужны полностью? или то что прихожит с патчем не сильно надо

Для инфраструктурных штук. Например, берёшь класс, достаёшь информацию о типе, оттуда достаёшь информацию о реализуемых интерфейсах и регистрируешь в IoC контейнере данный класс как реализацию всех этих интерфейсов. Или мой случай. Я обработчики команд и запросов помечаю всякими разными интересными атрибутами, например [RunInTransaction], и если у обработчика стоит данный атрибут - я автоматом прикручиваю ему декоратор, который заверенёт его вызов в транзакцию. Банально меньше кода ведь писать))

Это лучше делать в компайлтайме

тебе объекты твои в рантайме нужны полностью? или то что прихожит с патчем не сильно надо

не особо понял вопрос

ну вот есть у тебя допустим 10 полей у объекта. приходит патч на еще 3 каких-то поля не вхожих в эти 10, расширяющих его. потом в логике эти 3 поля участвуют?

или можно их куда-нить в кэш скинуть и доставать lazy при необходимости?

считай что у тебя основной объект в рантайме это таблица фактов и патчишь ты как будто таблицу измерений

или так не пойдет?

ну вот есть у тебя допустим 10 полей у объекта. приходит патч на еще 3 каких-то поля не вхожих в эти 10, расширяющих его. потом в логике эти 3 поля участвуют?

поля, которые не поддерживаются, вообще не должны приходить)

ааа

сруктура объекта строго статическая, конечно же

да блин хз, делай там декоратор

не знаю как правильно еще)

+ copy constructor, я понял. спасибо :)

+ copy constructor, я понял. спасибо :)

гениально

ты еще поспрашивай, мож я херню сказал, рили

в любом случае я бы не сильно используемые поля хранил бы не в памяти и грузил их по факту необходимсоти lazy load, это вот точно

вот я читаю вас и думаю как обойтись без instanceof но судя по всему никак

кодогенерация.

гениально

Если это сарказм, то я не понял)

?

не не, все реально правильно

оно многие проблемы решит

только писать дофига :-(

кодогенерация.

слишком тяжело, тут таких задач нет. там по сути вопрос как понять какая сущность приходит не через instnaceof всего лишь

слишком тяжело, тут таких задач нет. там по сути вопрос как понять какая сущность приходит не через instnaceof всего лишь

...откуда она приходит?

ситуации с instanceof в ФП решаются discriminated union / sealed class-ами, в ООП — паттерном visitor, но контекста я не знаю, может и не помочь

слишком тяжело, тут таких задач нет. там по сути вопрос как понять какая сущность приходит не через instnaceof всего лишь

ну я и говорю - весь вопрос какая информация о типах тебе доступна при сборке проекта что бы устранить необходимость спрашивать потом в рантайме.

схема такая. есть несколько сущностей таких как пользователь, заказ, рейс с его статусами (изменился гейт например или самолет на посадку зашел) и т.п. как только происходят изменения (пользователь создан и в его сущности появился код конфирмации и он confirmed: false, читай это состояние) - мы либо прям напрямую инжектим сервис нотификаций в эти сервисы, либо отправляем все на IPC и хавают изменения все интересующиеся, в том числе сервис нотификаций. и вот ему (сервису нотификаций) приходит - создай нотификацию с аргументами - data: any, template: стринга

надо понять какая сущность пришла в data: any и желательно без instnaceof чтоб не подвязываться именно на ООП (есть тема потом переписать нафиг на FRP без ООП)

ну я и говорю - весь вопрос какая информация о типах тебе доступна при сборке проекта что бы устранить необходимость спрашивать потом в рантайме.

считай что тут нет жесткой разницы в рантайме и не в рантайме, это ж жс

сборка там чисто номинально потому что надо транспилить TS в JS, по сути - всё

ситуации с instanceof в ФП решаются discriminated union / sealed class-ами, в ООП — паттерном visitor, но контекста я не знаю, может и не помочь

спасибо за наводку, подумаю

схема такая. есть несколько сущностей таких как пользователь, заказ, рейс с его статусами (изменился гейт например или самолет на посадку зашел) и т.п. как только происходят изменения (пользователь создан и в его сущности появился код конфирмации и он confirmed: false, читай это состояние) - мы либо прям напрямую инжектим сервис нотификаций в эти сервисы, либо отправляем все на IPC и хавают изменения все интересующиеся, в том числе сервис нотификаций. и вот ему (сервису нотификаций) приходит - создай нотификацию с аргументами - data: any, template: стринга

при отсутствии энамов и sealed-классов как-то всё равно, как делать, мне кажется :)

ну я собственно поэтому и спросил как правильно, сам думаю что можно как угодно)))

энамы есть

если захочу через нативный жс могу поиграться с Symbol

есть надёжный свитч/матчинг по ним?

в смысле надежный???

чтоб в рантайме не выкинул чего?