после проверки на наличие ключа TS должен бы вывести A & { y: unknown }
В этом месте не будет выведения типа, а только сужение из уже имеющегося множества. Изначально у нас тип param равен A | B , так что в дальнейшем он не может вывести в другой тип
Там нежданчик не в месте проверки и вывода типа param , а в месте вызова функции. Странно то, что можно в функцию передать obj, потому что он не соответствует типу A | B, который принимает функция. Тип у obj выводится компилятором как { x: number, y: null }, но функция принимает либо { x: number }, либо { x: number, y: number } . Там на месте y может быть любой тип, и функция всё-равно его схавает. А ты вроде как ждёшь только A или B, в котором y будет number.
Всё-таки важно. Она должна быть удобной (чтобы ты ей пользовался, а не избегал) и обязательной (иначе в один момент просто забудешь запускать проверки).
Создавать модуль, создавать типы с которыми он работает
Так я рефакторю typescript-проект, у меня типы уже есть.
создавать новые интерфейсы для методов, если параметры поменяются
Это не так работает. Меняются параметры функции -> тайпскрипт выводит сигнатуру этой функции -> автоматом проверяет, все ли использования этой функции корректны. Если я где-то забыл перейти на новую сигнатуру у меня просто выскочит ошибка с указанием места.
Теперь перейдём в мир js. Что там будет, если поменять сигнатуру функции? Да ничего, если вы забудете где-то поменять параметры, то об этом узнаете только в рантайме. Повезёт, если сразу станет понятно проблемное место.
Если же меняется структура данных, которыми манипулирует функция, т.е. интерфейсы, то их поправить занимает не так много времени. При этом опять же, тс сразу покажет, где эти типы используются и
Где тут ускорение рефакторинга ?
Рефакторинг - это не только изменение кода, но и проверка на корректность. Изменение кода обычно быстрее, так как я сразу вижу всё что нужно исправить. Проверка тоже быстрее, потому что часть глупых ошибок, типа "забыл изменить имя поля, забыл добавить второй параметр в функцию, опечатался в названии" просто исчезают навсегда. Пример я приводил - поменять поле name в одной структуре, не трогая другую. Простым поиском и заменой тут дело не решишь. Могу ещё примеров накидать
Противники типизации никак не могут понять, что они тоже в конечном итоге работают с типами, потому что данные, которыми манипулируют не рандомные, а имеют какую-то структуру. Только вот типы у них "вылазят" в самый последний момент, когда их уже используют. Но из-за динамичности языка где-то на пути от, условно получения из апи до вывода на экран, какие-то типы могут быть неправильно преобразованы или использованы. Тайпскрипт просто позволяет выявить это раньше, до запуска.
Это как писать программу по ТЗ. JS - это устные договорённости, которые все забывают или искажают, неверно интерпретируют (потому что описано размыто). Поэтому нужный результат долго получается - слишком много доделок. TS - это нормальное ТЗ записанное в условном конфлюенсе, где всё оговорено, где пограничные случаи описаны, так что ты просто читаешь и пишешь. Мне вот по второму способу удобнее и быстрее работать.
Как минимум имз за того что раза в три больше кода писать надо.
Берите больше, в 10 раз!
Я вот код больше читаю/исправляю, чем пишу. Писать мне всякие AI-ассистенты и IDE помогают. А вот время на поиск глупых ошибок, вроде опечаток имени полей в рантайме, почему-то противники тайпскрипта не учитывают. Видимо они реально только пишут код, но не сопровождают его.
Не видел еще проектов, крооме блокчейнов где type sacript был бы прямо неоьходим.
Ну ничто не необходимо, так-то можно и на бэке всё на ассемблере писать или сразу в машкодах. Типизация это просто вопрос удобства разработки и уменьшения проблем до запуска программы.
Попробуйте порефакторить любой большой js проект. Например, есть 2 эндпоинта /api/user и /api/item. Они возвращают схожие объекты с полем name: `{ id: 1, name: 'name', ... }`. Далее, эти данные разлетаются по всему приложению на сотню различных страниц. Теперь мы хотим переименовать name в fullName для юзера, но оставить name у item нетронутым. Typescript позволит сразу увидеть, где мы используем старое поле и где нужно его сменить (Ну и чем больше описано типов, тем проще что-то добавлять или изменять). Для js же обычно всё вылезет в рантайме.
Ответ вам дали. Риск потерять деньги есть везде, любой банк может заблочить счета если сильно захочет (или его вынудят). У меня у друга блочили счета просто потому что где-то в другом городе был должник, который был его полный тёзка с той же датой рождения. Т.е. за чужой долг блочили счёт моего друга. А ещё вас могут внезапно для всех объявить экстремистом, например, если когда-то кому-то что-то переводили.
Хочется меньше рисков - переводите мелкими партиями из разных источников, переводите с карты, на которой мало денег и т.д.
Так а токсичность-то в чём? Простая же логика: язык A позволяет допустить класс ошибок N, а язык B - N-5 (условно). Если переписать программы с A на B, количество ошибок уменьшится. Меньше ошибок - лучше мир. Ну допускает автор такие вполне логичные (ему и мне и ещё некоторым людям) мысли, и что?
А вот взять ваш комментарий, так уже в третьем предложении началось "детский максимализм или рвение неофитов", "сомнения в адекватности этих коллег...".
почему в один момент блокировки в РФ телеграма прекратились, и риторика гос. говорящих голов изменилась с "там террористы и наркоманы сидят, не пользуйтесь" до "подписывайтесь на наш телеграм канал"
куда делась плашка "вечно бесплатный"? неужели вы тоже не сдерживаете обещаний?
Технически "дынц-дынц-дынц" максимально адаптирован под
все девайсы, на самом деле. И не только дынц, а всё современное. Хорошо сведённое нормально слушать и на блютус колонке, и в хороших наушниках, и на аудиосистеме.
Ну прогоните пинк флойд через компрессор и иквалайзер улыбочкой, будет вам громко и сочно.
Достаточно скверно (по сегодняшним меркам) сведены и отмастерены, на самом деле. Если включить рядом Pink Floyd и что-то современное, разница будет очевидна. В первом случае - тихий мутный звук, во втором - громко и сочно. Что из этого лучше уже каждый для себя решает. Технически "дынц-дынц-дынц" на голову выше в техническом плане, а вот в музыкальном уже дело вкуса.
"полный загруз" вообще по всем частотам
Как раз в новых песнях, потому что техника сведения очень сильно изменилась. Сейчас спектрограмма может выглядеть как кирпич, но и динамика при этом сохраняется. Если посмотреть на старые песни, то низа и верха там проблемные, и динамика похуже
В этом месте не будет выведения типа, а только сужение из уже имеющегося множества. Изначально у нас тип
paramравенA | B, так что в дальнейшем он не может вывести в другой типТам нежданчик не в месте проверки и вывода типа
param, а в месте вызова функции. Странно то, что можно в функцию передатьobj, потому что он не соответствует типуA | B, который принимает функция. Тип у obj выводится компилятором как{ x: number, y: null }, но функция принимает либо{ x: number }, либо{ x: number, y: number }. Там на местеyможет быть любой тип, и функция всё-равно его схавает. А ты вроде как ждёшь только A или B, в которомyбудетnumber.Всё-таки важно. Она должна быть удобной (чтобы ты ей пользовался, а не избегал) и обязательной (иначе в один момент просто забудешь запускать проверки).
Так я рефакторю typescript-проект, у меня типы уже есть.
Это не так работает. Меняются параметры функции -> тайпскрипт выводит сигнатуру этой функции -> автоматом проверяет, все ли использования этой функции корректны. Если я где-то забыл перейти на новую сигнатуру у меня просто выскочит ошибка с указанием места.
Теперь перейдём в мир js. Что там будет, если поменять сигнатуру функции? Да ничего, если вы забудете где-то поменять параметры, то об этом узнаете только в рантайме. Повезёт, если сразу станет понятно проблемное место.
Если же меняется структура данных, которыми манипулирует функция, т.е. интерфейсы, то их поправить занимает не так много времени. При этом опять же, тс сразу покажет, где эти типы используются и
Рефакторинг - это не только изменение кода, но и проверка на корректность. Изменение кода обычно быстрее, так как я сразу вижу всё что нужно исправить. Проверка тоже быстрее, потому что часть глупых ошибок, типа "забыл изменить имя поля, забыл добавить второй параметр в функцию, опечатался в названии" просто исчезают навсегда. Пример я приводил - поменять поле name в одной структуре, не трогая другую. Простым поиском и заменой тут дело не решишь. Могу ещё примеров накидать
Противники типизации никак не могут понять, что они тоже в конечном итоге работают с типами, потому что данные, которыми манипулируют не рандомные, а имеют какую-то структуру. Только вот типы у них "вылазят" в самый последний момент, когда их уже используют. Но из-за динамичности языка где-то на пути от, условно получения из апи до вывода на экран, какие-то типы могут быть неправильно преобразованы или использованы. Тайпскрипт просто позволяет выявить это раньше, до запуска.
Это как писать программу по ТЗ. JS - это устные договорённости, которые все забывают или искажают, неверно интерпретируют (потому что описано размыто). Поэтому нужный результат долго получается - слишком много доделок. TS - это нормальное ТЗ записанное в условном конфлюенсе, где всё оговорено, где пограничные случаи описаны, так что ты просто читаешь и пишешь. Мне вот по второму способу удобнее и быстрее работать.
То есть фактически без проверок на ошибки, потому что ломаный код всё равно можно запустить.
Можно пример?
Сочувствую. В моём тайпскрипте по-другому.
Берите больше, в 10 раз!
Я вот код больше читаю/исправляю, чем пишу. Писать мне всякие AI-ассистенты и IDE помогают. А вот время на поиск глупых ошибок, вроде опечаток имени полей в рантайме, почему-то противники тайпскрипта не учитывают. Видимо они реально только пишут код, но не сопровождают его.
Зачем? Уже есть typescript. Система типов там ощутимо лучше C#. Некоторых языковых фич C# может и не хватает, но не так чтобы прям критично.
Ну ничто не необходимо, так-то можно и на бэке всё на ассемблере писать или сразу в машкодах. Типизация это просто вопрос удобства разработки и уменьшения проблем до запуска программы.
Попробуйте порефакторить любой большой js проект. Например, есть 2 эндпоинта
/api/userи/api/item. Они возвращают схожие объекты с полем name: `{ id: 1, name: 'name', ... }`. Далее, эти данные разлетаются по всему приложению на сотню различных страниц. Теперь мы хотим переименоватьnameвfullNameдля юзера, но оставитьnameу item нетронутым. Typescript позволит сразу увидеть, где мы используем старое поле и где нужно его сменить (Ну и чем больше описано типов, тем проще что-то добавлять или изменять). Для js же обычно всё вылезет в рантайме.Ответ вам дали. Риск потерять деньги есть везде, любой банк может заблочить счета если сильно захочет (или его вынудят). У меня у друга блочили счета просто потому что где-то в другом городе был должник, который был его полный тёзка с той же датой рождения. Т.е. за чужой долг блочили счёт моего друга. А ещё вас могут внезапно для всех объявить экстремистом, например, если когда-то кому-то что-то переводили.
Хочется меньше рисков - переводите мелкими партиями из разных источников, переводите с карты, на которой мало денег и т.д.
Кстати, в чем проблемы с законом?
Вот пополнение.
Пополнение
Банковские карты принимает https://neocrypto.net/ . Ну и всегда можно p2p переводить. Как тут хз, но есть всякие https://www.bestchange.com, где есть продавцы с рейтингом.
Дальше надо ввести номер и вроде ФИО, чтобы получить базовую верификацию. С ней доступны вот такие лимиты
Лимиты
ой как неожиданно
Ага, но заявляли же нечто другое:
On top of that, Telegram is free and will stay free — no ads, no subscription fees, forever.
Так-то я не против платных подписок. Но если одно обещание нарушили, то в другие меньше веры.
А вот выше один спец по Си не смог пройти тест на знание UB.
Так а токсичность-то в чём? Простая же логика: язык A позволяет допустить класс ошибок N, а язык B - N-5 (условно). Если переписать программы с A на B, количество ошибок уменьшится. Меньше ошибок - лучше мир. Ну допускает автор такие вполне логичные (ему и мне и ещё некоторым людям) мысли, и что?
А вот взять ваш комментарий, так уже в третьем предложении началось "детский максимализм или рвение неофитов", "сомнения в адекватности этих коллег...".
Но токсик именно автор, а не вы, ага
И в довесок:
почему в один момент блокировки в РФ телеграма прекратились, и риторика гос. говорящих голов изменилась с "там террористы и наркоманы сидят, не пользуйтесь" до "подписывайтесь на наш телеграм канал"
куда делась плашка "вечно бесплатный"? неужели вы тоже не сдерживаете обещаний?
У меня встречный вопрос. Чем занимаются люди из вселенной фара, что им нужно каждый день
Помимо замыканий, инкапсулировать можно на уровне модулей в Haskell/F#/Ocaml/Rust
все девайсы, на самом деле. И не только дынц, а всё современное. Хорошо сведённое нормально слушать и на блютус колонке, и в хороших наушниках, и на аудиосистеме.
Не будет
Достаточно скверно (по сегодняшним меркам) сведены и отмастерены, на самом деле. Если включить рядом Pink Floyd и что-то современное, разница будет очевидна. В первом случае - тихий мутный звук, во втором - громко и сочно. Что из этого лучше уже каждый для себя решает. Технически "дынц-дынц-дынц" на голову выше в техническом плане, а вот в музыкальном уже дело вкуса.
Как раз в новых песнях, потому что техника сведения очень сильно изменилась. Сейчас спектрограмма может выглядеть как кирпич, но и динамика при этом сохраняется. Если посмотреть на старые песни, то низа и верха там проблемные, и динамика похуже