В обновлением документа о генериках и конрактах все часто ссылаются на этот пост, о том что это плохо и ой выкиньте.
(сама статья
https://ericgreer.info/post/my-case-against-go-contracts/)
Ну давай разберем по частям, тобою написанное ))
— Highly Variable Function Signtures
Приводится 3 фции...
func One(x string, b bool)(err error)
func Two(type T)(x string, y T) error
func Three(x string)(bool, error)
А ведь люди с питона и джавы перешли, начали писать типы или имя параметра перед типом. Некоторые тоже жаловались.
Вот только что сложного? Мыж нормально читаем вот такое, почему никто не возмущается, что много скобочек?
func (m *Moo) Four(x string) (int, error)
— Too Similar to Interfaces
Привет duck-typing :) Только интерфейсы про реализацию, а конракты про тип. И похожи они будут из-за всего дизайна Го: для реализации интерфейса(конракта?) не надо будет это тащить в зависимости (для реалзации
io.Reader не надо импоритть
io)
— Function Signature Bloat
Теплое с мягким. Предлагается новый инструмент для написания кода, а люди хотят это zero-cost abst...в общем без изменений кода. Немного нагло звучит. Да, дженерики нужны, без них жить можно, это не противоречие.
func (c *Car) Drive(type T1 selfDriving, type T2 autoNavigation)(directions Directions, drivingCPU []T1, navigationCPU []T2) (t *Trip, err error) {}
func (c *Car) Drive(directions Directions, drivingCPU []T1, navigationCPU []T2) (t *Trip, err error) {}
Для меня эти 2 варината одинаково тяжело читаются. Ой..
— The Proposal is Huge
Без примеров статья будет меньше, а так, кстати, неплохо разжована и сравнение хорошее.
"Понравившиеся" фразы:
— Big function signatures increse cogntitive overhead and make us worse programmers.
ок, а в чем проблема с дженериками? Все оставшиеся фции останутся как были. Кстати, причем большая фция к большому(?) описанию? Так и документацию можно начать ругать, ведь в коде все написано.
— Let’s not forget that a contract also has a spec that you have to click into and understand.
ну так у Го и без конрактов есть спека))0))0))
