kouzdra (kouzdra) wrote,
kouzdra
kouzdra

Category:

goбъектное-4

Теперь о грустном, то есть о недостатках данной модели:

структурное "наследование" порождает понятную проблему: например синтаксическое дерево самого go наследует не абстрактный тип Ast, а сразу interface{} (который как легко понять в go является функциональным аналогом Object в Java). Что порождает понятные проблемы с типовым контролем (точнее его отсутствием там, где его хочется).

Просто описать:
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 избыточный синтаксис - но это дело вкуса.

Upd: Еще один неоднозначный вопрос - запрет использовать в качестве анонимных полей интерфейсы. Единственная проблема, которая тут возникает - это необходимость генерировать стабы для вызова методов из интерфейсов. Нежелание авторов понятно, с другой стороны - как мне кажется возможность "динамического наследования" может быть полезна
Tags: go, goбьектное, Компутерщина, Языки программирования
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments