PT
А в 3.0 уже точно сорбет будет?
Size: a a a
2019 October 17
IM
Оно и не заменяет, хотя в сорбете есть динамические типы, но они слишком простые
вообще, для каких-то проектов на каких-то масштабах заменят. но это если юзать драй-тайпс чисто как способ аннотировать типы
IM
Кек, это больше похоже на правду. В какой-то момент понимаешь ещё что нахуй архитектуру и прочее, потому что проблемы в 99.99% в коммуникациях и процессах
а архитектура это не коммуникации и процессы? 🤔
AD
А в 3.0 уже точно сорбет будет?
не будет там сорбета
AD
а архитектура это не коммуникации и процессы? 🤔
скорее стандартизация и поиск проблем
AD
но я говорил про архитектуру в духе “как правильно файлы в рельсе сделать и что выбрать, драй или трейлблейзер"
JĐ
не будет там сорбета
А что там будет? Я в статейках про это читал что "будет как сорбет но часть языка"
AD
А что там будет? Я в статейках про это читал что "будет как сорбет но часть языка"
там будет своя имплементация такой штуки
JĐ
Я не понимаю почему в рубисты решили что пихать аннотации типов в отдельный файл это хорошая идея.
IM
это ж реально хорошая идея
AD
Я не понимаю почему в рубисты решили что пихать аннотации типов в отдельный файл это хорошая идея.
А почему это плохая идея?
JĐ
А почему это плохая идея?
Потому что тело функции и сигнатура в разных местах.
В питоне ты смотришь на функцию и сразу видишь тайпхинты, хоть ты cat ом свой код читаешь. А вот это вот с отдельным файлом для сигнатур вменяемо работать будет только с громоздкими ide.
В питоне ты смотришь на функцию и сразу видишь тайпхинты, хоть ты cat ом свой код читаешь. А вот это вот с отдельным файлом для сигнатур вменяемо работать будет только с громоздкими ide.
IM
тут дело в чём.
у функции есть сигнатура с типами всегда, в том или ином виде. это данность.
но её может не быть в коде даже в статически типизированных языках. ни в исходном файле, ни в соседнем файлике для описания интерфейсов
у функции есть сигнатура с типами всегда, в том или ином виде. это данность.
но её может не быть в коде даже в статически типизированных языках. ни в исходном файле, ни в соседнем файлике для описания интерфейсов
IM
хороший язык даст возможность заиметь сигнатуры функций и не описывать их в коде. когда у тебя сигнатуры в соседнем файле, у тебя эта возможность появляется
IM
вывод типов, генерация, т.п. — всё это будет работать в руби, если запилить
IM
с аннотациями как в питоне такое ~невозможно~ сложнее, и это грустно
IM
как зачёркивать, аа
IM
ну ладно
IM
в питоне тип-то вывести можно, теоретически, но эта информация потеряется как только ты выгрузишь программу из памяти. а тут персистентно