Обновить
25
0
ApeCoder@ApeCoder

Разработчик

Отправить сообщение

Почему антригарантия. Для тех целей, для которых его создают, он гарантирует жрать и причмокивать. Другое дело, что мне данная практика не нравится.


Т.е. если его создают, то для того. чтобы результат обладал какими-то свойствами. Совокупность этих свойств про которые мы знаем и есть тип. Если мы знаем это в дизайн тайм, то тип статический. Концептуально.

Для того, чтобы сделать это ответственно, надо проанализировать все места где она используется и понять, что они расчитаны на новый тип результата.


При статической типизации вам это поможет сделать анализ типов и рефакторинги.

Вот это наверное и есть гарантия — какой-нибудь int упадет с ошибкой

Думаю, тем что там есть развитые инструменты для описания типов. Т.е. можно декларировать типы переменных значений и т.д.


Во-вторых обязательностью. Как только вы делаете проверку обязательной у вас уже получаются ситуации которые работали бы вполне пока бы вы не вошли в специфический кейз, но статическим контролем будут запрещены.

Насколько я понял, он гарантировано предоставляет. Нет?

разница в умолчаниях, удобстве и быстродействии в результате кодовая база разная

Либо они являются концептуально статически типизированным языком, написанным поверх динамического, либо они слабее поддерживаются или менее выразительны (т.е. например там нет каких-то аннотаций для типов).

Вопрос, что она делает вместо того, чтобы упасть с ошибкой. И насколько очевидно то, что она делает. В некоторых случаях лучше уж упасть.

И сколько нужно создавать под-типов одного типа?

Очевидно в данном случае два.


Данное решение является самоубийством!

Любое решение является самоубийством, если его применять везде и для всего.

у него тип mock.MagicMock :) или mock.MagicMock — я не знаю питона глубоко

не думая о том, что это за функция.

"функция" это уже тип.

"Это не типизация, это… — «утиная типизация». Что угодно с ".len()" сойдёт в этом месте.

Утиная типизация это тоже типизация. Это просто не номинативная типизация а структурная.

Я и говорю что прослойка не знает. Но в том месте где вы пишете foo.len() вам надо знать что при выполнении туда попадет что-то у чего есть метод len.

Спасибо, прочёл. Но как это в коде реализуется?

Код знает какие типы могут быть. И может делать выводы о гарантиях. В typescript прочитайте про discriminated unions и type guards


https://www.typescriptlang.org/docs/handbook/advanced-types.html

Я совершенно с вами согласен. Утиная типизация фактически это структурная типизация. Она может быть статической и динамической. Даже если она динамическая чтобы ей пользоваться надо статически о ней рассуждать. Просто без поддержи компилятора.

> У объекта может быть вообще враппер над rpc, который все вызовы всех методов тупо передаёт дальше.

Внутри враппера он не зависит от конкретного типа. Чтобы пользоваться враппером, надо понимать, какие методы там могут быть, а какие нет. То есть вывести в мозгу тип.
Только не надо писать: «Поставь other_param?: string». Это не решение проблемы.

Почему не решение?

Даже программируя на динамическом языке люди используют неявно статическую типизацию, так как для того, чтобы написать x.y(z) надо знать что у объекта x есть метод y, который принимает параметр z, а это и есть тип.
Я не разбираюсь кто больше виноват мне это вообще не интересно. Просто интересно получить представление о команде и стиле коммуникации.

У вас были проблемы с конкретными симптомами — вы их выносили на общее обсуждение?

Информация

В рейтинге
7 084-й
Откуда
Россия
Дата рождения
Зарегистрирован
Активность