g
ррр, хотеттьь https://github.com/nim-lang/RFCs/issues/168
Size: a a a
2021 May 24
g
наконец то хоть какое то подобие интерфейсов
g
А то функции для gtk вот так выглядят
g
а будет один концепт Buildable и все будут реализовывать, полагаю
A
а почему простые дженерики не работают?
A
в том плане, что в Nim они же unconstrained
g
а в чем будет разница? тоже перечисление но в ограничениях дженерика
g
так какой смысл в дженерике без ограничений, он ничего не говорит о себе, пока не впихнешь неподходящий тип
A
ну да, он вылетит дальше конечно
g
А нужно именно интерфейс, вот тут например все они "GtkBuildable allows objects to extend and customize their deserialization from ui files."
g
Вообще удивительно что за 14 лет ничего похожего на интерфейсы не появилось, обычно наоборот в новых языках
g
ооп нет, но интерфейсы в том или ином виде всегда есть
A
а нельзя написать type Buildable = Icon | Dialog | ... ?
А в функции просто self: Buildable
А в функции просто self: Buildable
A
или тут какая-то фишка именно в ооп ?
g
хмммм, если оно будет через тип сумму, то что будет когда вызовут метод у C который есть у A но нет у B, при том под C сейчас B
g
сложна, но вроде бы не подойдет
VB
я и говорю, что-бы только ни придумать, лишь-бы ООП не реализовывать, но продолжать пытаться им пользоваться...
A
я не уверен, что это тип-сумма как её понимаем обычно, это просто алиас по сути (наверное)
g
в любом случае концепты на порядок лучше, когда у тебя будут сложные цепочки реализаций интерфейсов, ето получается будет тип сумма C = A|B
а когда чтото будет реализовывать A и B и D то это что, F = C|D или еще хуже F = A|B|D, короч ненене, жуть, нужно обычное объединение методов в одну структурную единицу, у go вроде найс получилось
а когда чтото будет реализовывать A и B и D то это что, F = C|D или еще хуже F = A|B|D, короч ненене, жуть, нужно обычное объединение методов в одну структурную единицу, у go вроде найс получилось