А
хотя если честно до сих пор не понимаю смысла мономорфизации, для жс таргета
Size: a a a
2020 March 04
А
причём только для валидации
А
если в JS можно тупо в рантайме пробросить классы или метаинформацию типов скажем
А
тогда достаточно будет один раз в foo зайти
M中
MaxGraey
Я имею вииду по декоратору понимать что эту функцию нужно трансформировать и подготовить все для этого
seems legit
не уверен что не вылезут другие подводные камни, но в любом случае спасибо!
не уверен что не вылезут другие подводные камни, но в любом случае спасибо!
M中
Evgenii Moiseenko
вам случайно не type reification нужен?
https://eli.thegreenplace.net/2018/type-erasure-and-reification/
https://eli.thegreenplace.net/2018/type-erasure-and-reification/
да, это оно
буду знать что гуглить, спасибо!
буду знать что гуглить, спасибо!
MM
А откуда вообще берутся N проходов? Почему нельзя за первый проход запомнить все generic-и, а дальше сделать ещё один проход, который уже всё мономофизирует?
M中
если в JS можно тупо в рантайме пробросить классы или метаинформацию типов скажем
у меня есть агрументация, но я не вижу смысла озвучивать ее здесь
энивей вам тоже спасибо за диалог
энивей вам тоже спасибо за диалог
А
А откуда вообще берутся N проходов? Почему нельзя за первый проход запомнить все generic-и, а дальше сделать ещё один проход, который уже всё мономофизирует?
проходов по foo будет несколько
А
в любом случае
А
ведь фактически для каждого типа надо из foo генерировать новую функцию
M中
А откуда вообще берутся N проходов? Почему нельзя за первый проход запомнить все generic-и, а дальше сделать ещё один проход, который уже всё мономофизирует?
это как раз и предложили выше
я не то чтобы рассматривал решение через n проходов, просто хотел этого избежать)
я не то чтобы рассматривал решение через n проходов, просто хотел этого избежать)
А
А откуда вообще берутся N проходов? Почему нельзя за первый проход запомнить все generic-и, а дальше сделать ещё один проход, который уже всё мономофизирует?
за один проход запомнить все дженерики - это значит всё равно потом залезть N раз в foo, пройдясь по всем запомненным дженерикам
MM
Да, разумеется, без этого не обойтись. Просто не обязательно N раз бежать по всему коду.
А
Да, разумеется, без этого не обойтись. Просто не обязательно N раз бежать по всему коду.
ну это понятно
А
но запоминать кстати всё равно придётся
M中
Да, разумеется, без этого не обойтись. Просто не обязательно N раз бежать по всему коду.
а, ну это ограничение апи
я внедряюсь в уже существующий пайплайн плагинов которым дан апи визитора
я внедряюсь в уже существующий пайплайн плагинов которым дан апи визитора
M
Вообще то это может вылиться не в N проходов а намного хуже)
class Boo<T> {
boo<U>() {
…
}
}
class A<T> {
t = new Boo<T>()
foo<U>() {
this.t.boo<U>()
}
}
ну и понятное дело все может быть куда сложнее и цикличнее. Да исобственно вся программа может содержать кучу дженериков а validate вызов скрыт под огромными слоями абстракций
class Boo<T> {
boo<U>() {
…
}
}
class A<T> {
t = new Boo<T>()
foo<U>() {
this.t.boo<U>()
}
}
ну и понятное дело все может быть куда сложнее и цикличнее. Да исобственно вся программа может содержать кучу дженериков а validate вызов скрыт под огромными слоями абстракций
AT
А что насчёт всунуть метод
validate в нужные типы посредством monkey patching и заменить вызовы функции на вызовы этого метода?M中
А что насчёт всунуть метод
validate в нужные типы посредством monkey patching и заменить вызовы функции на вызовы этого метода?дак нет типов в рантайме, type erasure в деле