| |||
|
|
goбъектное-4 type Ast interface { } И затем из него наследовать интерфейсы и указывать его в качестве типа параметра etc по понятной причине бесполезно. Обходится это просто - созданием в Ast какого-нибудь фиктивного метода (на сам деле достаточно его сделать просто локальным - за пределами пакета заимплементить его кроме как через наследование невозможно), но решение несколько кривовато. Второй момент - структуры замечательно эффективны, а вот то, что интерфейсы виртуализуют абсолютно все, может и не быть столь уж замечательно. Хотя я понимаю причины такого выбора авторов - на основе KISS-принципа. Теперь о том, что мне лично бы хотелось, и что несложно добавить: Imho не хватает pattern-matching'а. Совершенно очевидный кандидат - switch по типам - что-то типа switch p:=p.(type) { case ColoredPoint2D{x, y, color:"red"}: return x+y ... Никаких проблем тут я не ожидаю Разрешение вытаскивать в интерфейсы и поля структур. Понятно, что если у нас есть прокся к методам, то ничего не мешает вытащить туда и инфу для доступа к полям. Более спорный вопрос - tagged unions: интерфейсы, как я уже грил, некоторый оверкилл, кроме того switch по ним не столь эффективен - просто переходом по табличке не выйдет. Ну и хочется от компилятора контроля за тем, что все варианты разообраны, если список закрыт. Тут сложнее - но вариант например ввести тип union: type T [T1 | *T2 | T3 ...]Который предваряет значение тэгом с номером варианта (если переменная локальна - то размер по максимум, если константа или копия в куче - по фактическому размеру). Остается правда открытым вопрос с сабтайпингом - видимо нет (потому что возвращаемся к вопросу о значениях тэгов), хотя допустимо динамическое преобразование к более узкому типу. Но это вопрос диспутабельный. Еще хочется local type inference и простейшего параметрического полиморфизма, но тут я разделяю опасения авторов на тему переусложнения. Ну и мне не очень нравится несколько imho избыточный синтаксис - но это дело вкуса. |
||||||||||||||||