Comments 7
Хорошая статья. Но, когда кто-то рассказывает о недостатках динамической типизации, обычно это делают как-то так: берете револьвер, заряжаете полный барабан, взводите курок, направляете в ногу, стреляете… вот! Видели?! Вы выстрелили себе в ногу! Нет чтобы рассказать о проблеме вариативности, например, или о типах в сигнатурах методов в браузерных API… Мне кажется, используя ванильный JS и тайплинтинг (TS + JSDOC) — можно писать вполне надежный и качественный код. Во всяком случае, в списке проблем, проблемы с типами у вас будут где-то на предпоследнем месте. Я это к тому, что у TS куча недостатков, но не стоит о них так уж сильно беспокоится, «бутылочное горлышко» у вас в другом месте.
P.S. В списке способов проверки типов в рантайме не хватает конструктора. Да, это мутабельное свойство, но перезаписывать его — это все равно что ударить по компу бейсбольной битой и потом удивляться что код не пашет… Ну то есть при желании можно все на свете поломать, даже при самой строгой типизации.
P.S. В списке способов проверки типов в рантайме не хватает конструктора. Да, это мутабельное свойство, но перезаписывать его — это все равно что ударить по компу бейсбольной битой и потом удивляться что код не пашет… Ну то есть при желании можно все на свете поломать, даже при самой строгой типизации.
Абсолютно согласен с Вашим комментарием…
Каждая статья про недостатки TS скатывается в
— «давайте переопределим дефолтный метод»
— «мы все можем привести к any и ваш TS не работает»
— «сторонние библиотеки» (к всем актуальным на сегодняшний день библиотекам есть ts обертки).
У ТС есть недостатки, но Kotlin не даёт столько возможностей и удобства как TS. С Dart я не работал…
Каждая статья про недостатки TS скатывается в
— «давайте переопределим дефолтный метод»
— «мы все можем привести к any и ваш TS не работает»
— «сторонние библиотеки» (к всем актуальным на сегодняшний день библиотекам есть ts обертки).
У ТС есть недостатки, но Kotlin не даёт столько возможностей и удобства как TS. С Dart я не работал…
del
При работе с внешними данными всегда нужна валидация — минимум по набору данных и их типу, оптимально — по регулярке или функции валидации. Первый вариант подходит для разнообразных АПИ, второй — для пользовательских данных и приеме параметров через URL. В промышленных проектах это само собой разумеется, и "дыры" никакой нет.
UFO just landed and posted this here
Очень вторичная статься, всё это было уже написано не раз, не два и не три, и на хабре и на кучен других ресурсов.
Строгая типизация без статического анализатора приносит мало пользы, но хоть как-то улучшает ситуацию.
Sign up to leave a comment.
Сага о типизации и тайпчекинге для JavaScript