<@U33S3CR1A> Пока есть ощущение что не надо этого ...
# russiane
elizarov
10/12/2017, 1:59 PM@rrader Пока есть ощущение что не надо этого делать. Более конкретно, есть ощущение что для любой проблемы, которую можно решить с помощью макросов, есть вменяемое решение, которое требует какой-то другой, более простой фишки в языке, но не макросов.
r
rrader
10/12/2017, 2:04 PMМне просто интересно, это бы решило проблему с поддержкой макросов в IDE или нет?
e
elizarov
10/12/2017, 2:05 PMПроблемы там не только в этом. С макросами ломается очень много всякого IDE тулинга
elizarov
10/12/2017, 2:06 PMМожно сделать адеркватную IDE поддержку только для конкретного набора макросов решаюших конкретную задучу, но нельзя сделать адекватную IDE поддержку для произвольных макросов.
elizarov
10/12/2017, 2:06 PMПока есть вот такое ощущение
r
rrader
10/12/2017, 2:06 PMОк, спасибо
a
aleksey.tomin
10/13/2017, 4:30 AMНапрягает даже кодгенерация при загрузке/компиляции. Всё должно решаться без этого.
А то вот сейчас в нашей вроде хорошей штуке выяснилось, что т.к. это кодогенерация- то надо передавать параметр-константу, А очень-очень надо хотя бы при старте заполнять.
r
rrader
10/13/2017, 7:04 AM@aleksey.tomin не совсем понял, можно поподробнее?
a
aleksey.tomin
10/13/2017, 7:14 AMЭто не про kotlin.
Просто кодогенрерация библиотекой/компилятором это некоторый костыль, подпирающий архитектурные баги. В java таких багов полно. Надеюсь, в kotlin можно обойтись без них.
r
rrader
10/13/2017, 12:58 PMНу почему же, генерировать классы моделек на базе скемы базы данных, что в этом может плохого?
a
aleksey.tomin
10/13/2017, 1:01 PMВ теории ничего. На практике...
По БД не сталкивался, а вот всё остальное (по xml, по аннотациям) в итоге приводит к боли в отладке и понимании кода.
2 Views