Попробовал небольшой UI сделать для macOS и mingw....
# russian
a
Попробовал небольшой UI сделать для macOS и mingw. И если первое это в целом несложно (ну только некоторые вещи нельзя сделать без наследования от нативных классов, а делать это то ли не умею, то ли нельзя- не разобрался пока), То вот разработка интерфейса под винду - это ад какой-то - есть только “голое” win32 API а он написано какими-то неадекватами. Причём новое UWP недоступно совсем, и это плохо. И возникла такая мысль - а планируется ли сделать поддержку .net в MPP? Там и UI можно сделать человеческий, и выбор API больше, и windows-разработчики смогут нормально использовать наши библиотеки. При этом с новым IR наверняка IR->CIL несложно сделать...
TL;DR "несложно" - это в теории, а так это целый новый бэкенд. Добровольцы приветствуются, но сейчас котлин команда из нового пилит WASM.
i
ну допустим просто взять и написать кодген (тем более с IR!) - это просто. а вот всякие сложные вещи типа стейтмашин и инлайнера - тяжело
b
Мы стараемся делать большую часть работы используя IR. Конкретно, inline и suspend для JS и Native делаются по IR, для JVM это не так потому что нужна обратная совместимость.
По моему, с CIL будет больше вопросов и работы вокруг интеропа и всякого тулинга (IDE, билдтулы и т.п.).
i
да, это тоже страшно
но я только с кодгеном IL работал, поэтому сразу локализую боль там
a
Скорее будут проблемы с множественным наследованием в CIL.
b
кажется чисто котлиновская модель наследования должна мапиться просто, а с обратным (интероп) могут быть сложности.
a
Да, я именно про это- надо же будет как-то отображать системные классы. В том числе и те, от которых идёт наследование
a
Обратный интероп - дело десятое. И добавить множественное наследование в таргет не проблема. В языке оно уже де-факто есть. А вот компилятор писать...
a
Вряд ли это сложнее JS или любого native. Вопрос в ожидаемой пользе
a
Не сложнее, примерно так же. Но, как я писал, это пара лет работы
b
как я писал, это пара лет работы
поверх IR инфраструктры, должно быть сильно проще, если особо не думать про интероп
a
Компилятор из IR в CIL все равно писать.
b
это должно быть достаточно просто
a
Теоретически и JS IR сделать просто. Но пока фурычет далеко не все
🧌 1
b
Единственное про CIL возможно нет удобной готовой инфраструктуры для генерации доступной из JVM, как ASM.
i
для JS же тоже тулов нет
и для llvm тоже только сгенерированный бинд
a
Ну идейно они очень похоже, кроме того, CLR планировался как общий рантайм аля трюфль, там такое должно быть.
b
для JS того что у нас уже есть нам хватает
llvm тоже только сгенерированный бинд
этого хватает
i
и получается, что придется портировать какой-нибудь mono.cecil на jvm?
b
либо написать свой
🙂
Теоретически и JS IR сделать просто. Но пока фурычет далеко не все
С JS у нас сейчас в основном проблемы с миграцией существующего кода, особенно такого который завязался на какие-то особенности про которые мы ничего не гарантировали. Плюс какие-то вещи мы пытаемся поменять.
Плюс на пересечении с другими новыми подсистемами/сущностями, как, например, формат библиотек (klib) и kotlinx.serialization.
a
Да, мы уже все сломали в IR.
🙂 2
t
А потом хоп - и дотнет в нативный код скомпилировать!
a
Так как бы Substrat уже
b
По части Win32 API можно порекомендовать посмотреть как сделано в Eclipse SWT
i
@beholder вы сейчас вообще не про то: swt основан на биндах jni из jvm. а мы вообще про таргет ir2cil