Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kouzdra ([info]kouzdra)
@ 2013-07-06 11:42:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:go, goбьектное, Компутерщина

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


(Добавить комментарий)


[info]horsh
2013-07-07 01:21 (ссылка)
"Pattern matching for object-like structures in the Go programming language" C.Kaewkasi, P.Kaewkasi.

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2013-07-07 10:36 (ссылка)
Там только у них что-то странное в смысле реализации - на фига все эти traits и casestruct'ы я не понял - я имел в виду обычный совершенно типовой switch по обычным типам, только с сопоставлением не только с типами, но и с их компонентами.

(Ответить) (Уровень выше)