KD
Кстате, интерфейсы не подвезли еще?
Size: a a a
2021 January 09
VB
их вроде через эти, как их там, забыл название, делать надо. я пробовал - у меня нифига не вышло.
VB
на самом деле работать с протоколами в ниме вот вообще неудобно. наследование кривое, а варианты местами сурово неудобны как-раз из-за названий полей.
VB
да хватит уже...
VB
я уже этот диалог наизусть знаю
A
Если делаешь вариант, то ты не сможешь использовать одноименные поля в разных вариантах. Для кейса варианта ты не можешь использовать поле предка никак. Это вот реально бесит
вот прямо сейчас пытаюсь немного с этим побороться :)
VB
можно написать геттеры и сеттеры, но это нихрена вот неудобно
A
можно написать геттеры и сеттеры, но это нихрена вот неудобно
ну я почитал RFC 19 и сейчас думаю как внутреннее представление union{struct{}} должно выглядеть
A
конкретно - нужно ли делать какое-то объединение, чтобы одно поле, шаренное между kind, оставалось по сути общим, или это всё же разные части
VB
я не читал этот rfc, но юнион в ниме обычный юнион.
A
я не читал этот rfc, но юнион в ниме обычный юнион.
ну так в этом rfc немного срач на тему что просто так 1в1 это не наложить, потому как в итоге получится, что одно поле у разных kind может иметь разный тип, а такого в ниме быть не может
A
хотя опять же, я буквально 30 минут с этим ковыряюсь, пока вообще хз
VB
насколько я понимаю, общее поле между kind в силу того что это неименованый юнион - не гарантирует нахождение его в одном и том-же месте в памяти
A
насколько я понимаю, общее поле между kind в силу того что это неименованый юнион - не гарантирует нахождение его в одном и том-же месте в памяти
ну вот и мысль - может надо делать один union для нескольких kind тогда оно как раз будет одно для разных, но признаться как-то слишком замороченно выглядит
VB
ну вот и мысль - может надо делать один union для нескольких kind тогда оно как раз будет одно для разных, но признаться как-то слишком замороченно выглядит
я считаю что вот не надо так делать. очевидное лучше неочевидного.
VB
проще написать геттеры и сеттеры
A
я считаю что вот не надо так делать. очевидное лучше неочевидного.
я согласен. в целом я сейчас (через 30 минут :) ) застрял на том, что тот вариант, что написал Арак, вполне логичный и решает одну из проблем (разные типы для одного поля), но при этом там надо пилить составление из араковского варианта в обычный union.
A
если делать не как Арак (его так кстати произносить?) сказал, то проще, но вот тогда проблема с типами остаётся
A
проще написать геттеры и сеттеры
вот тут для меня проблема, что jsonutils тот же, да думаю много чего остального - не смогут в геттеры/сеттеры наверное
A
но в целом я вот тоже за свой короткий срок с нимом считаю, что эта вот проблема больше всего бесит, а RFC уже висит 5 лет что ли :(