Условно <T1, T2> T2 может быть только ковариантен Т1. Пример синтетический, но тем не менее

Это вряд ли. Ведь тут не скала)

Условно <T1, T2> T2 может быть только ковариантен Т1. Пример синтетический, но тем не менее

довольно базовая вещь. каждый раз сталкиваюсь с тем что не могу гуглить по флоу. видимо ты тоже в это упёрся. тип доходишь до самых начальных примеров и всё

Это вряд ли. Ведь тут не скала)

Собственно на ней пишу понемногу, поэтому привык.

довольно базовая вещь. каждый раз сталкиваюсь с тем что не могу гуглить по флоу. видимо ты тоже в это упёрся. тип доходишь до самых начальных примеров и всё

Да и по ТС инфы нет.

ну ты ведь про банальное T1: T2 спрашиваешь? а то слово ковариантен обычно в контексте отображений всплывает

Я спрашиваю в контексте Т2 является подмножеством Т1. Например унаследован от него.

ну дада. это почти в любых дженериках есть

function f<T, T2: T> (t: T2): T {

Где почитать можно про реализации? Если не сложно

просто проверил. как загуглить не знаю

алсо он кажись не может прочить следующие типы так что <T2: T, T> не выйдет

Хм

Подождите

Так не будет же работать это просто проверка на принадлежность типа Т2 к типу Т1 а не ковариантность. Т.е. если тип два унаследован от потомка Т1 то не заведется.

И в интерфейсе по идее не будет работать, к сожалению я с телефона, возможности проверить нет.

> Т.е. если тип два унаследован от потомка Т1 то не заведется так вот что такое ковариантность?

Сейчас попробую найти точное определение

https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B8_%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

есть ещё ссылка на статью Atlassian по scala но это оффтоп уже будет

ну дада. у тебя есть какой то контейнер?

опиши на скале/хаскеле

Можно сделать. У меня есть цель разобраться как это вообще делают в js лучшие практики.

нужный тип

хотя в хаскеле нет наследования и наверное не оче корректно

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

https://flow.org/blog/2016/10/04/Property-Variance/

вообще думал это импосибл описывать ко-контрвариативность контейнеров из-за мутабельности джс. но видимо ок

Спасибо!

да как раз нормально. Просто можно взять некий диапазон мутаций и его описать как деваинт типа. А всё, что не проходит в трэш кидать. Получается просто дрэйн потока.

ещё раз спасибо за ссылку, пойду читать

В флоу можно

вообще думал это импосибл описывать ко-контрвариативность контейнеров из-за мутабельности джс. но видимо ок

Это только для тс импосибл, лол

Из-за этого они пилят костыли, как ковариантность в коллбэках и промисах

довольно базовая вещь. каждый раз сталкиваюсь с тем что не могу гуглить по флоу. видимо ты тоже в это упёрся. тип доходишь до самых начальных примеров и всё

Во во во У меня тоже самое. Вроде и доки есть, а на деле все со скрипом идёт

да вроде все гуглится

Я сейчас уже прихожу к не очень приятному выводу насчет строгой типизации в js при использовании функционального подхода. Я не знаю как насчет flow (я им не пользовался), но тайпскрипт теряет огромную часть своей полезности, если ты активно используешь либы, типа ramda.

И в итоге, если эта типизация мало что гарантирует, но отнимает время (например на прописывание всяких порой сложных дженериков, а так же поддержание актуальности тайпингов сторонних либ, которые при обновлении тоже доставляют хлопот), то не лучше ли сконцентрироваться на тестах, и отказаться от строгой типизации вообще?

Я сейчас уже прихожу к не очень приятному выводу насчет строгой типизации в js при использовании функционального подхода. Я не знаю как насчет flow (я им не пользовался), но тайпскрипт теряет огромную часть своей полезности, если ты активно используешь либы, типа ramda.

Пожалуйста, расскажите где и как у Вас это происходит?

Ну например компилятор ts самостоятельно не может контролировать что у вас вернет какой-нибудь, например, R.applySpec.

Подождите, но ведь если вы используете это в рамках некой функции обёртки, всёравно придётся указывать возвращаемый тип.

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

И в итоге, если ты в теле условного applySpec что-то изменил, то ты внимательно должен соответственно изменить и дженерик. Так как сам компилятор о реализации ничего не знает, и на ошибку не ругнется. Короче ты теряешь контроль компилятора. А раз так, то стоит ли тратить время на все эти прописывания типов, которые контролируешь только ты?

Не проще ли переложить все на тесты?

ts ОЧЕНЬ полезная штука, но не при функциональном подходе

Да еще и все эти обращения через path или линзы. Ну вот как это может контролировать компилятор?

ts ОЧЕНЬ полезная штука, но не при функциональном подходе

замени ts на js

Ты считаешь что функциональный подход в js не несет пользы?

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

Можно писать обертки и явно указывать тип. Решение не идеальное, но все же. Либо вообще отказаться от использования типо-небезопасных функций. С flow есть tcomb - он в рантайме проверяет объекты на соответствие указанным типам. Годная штука

>> Можно писать обертки и явно указывать тип. Решение не идеальное, но все же. Если выбирать между этим решением и написанием тестов, то уж лучше тесты. Ибо данное решение вообще ничего особо не дает. Особенно если ты активно используешь либы типа ramda или lodash-fp >> Либо вообще отказаться от использования типо-небезопасных функций. все функциональные js-либы типо-небезопасны, к сожалению.

Не проще ли переложить все на тесты?

можно использовать подход эквивалентный clojure.spec - описывать типы динамически и проверять их потом проперти тестами - как плюс можно помимо банальной типизации проверять очень сложные инварианты которые в flow/ts не выразимы. ну и динамические валидаторы нам всеравно нужны для внешних данных. для жса есть tcomb-generate, runtypes-generate ну и сам jsverify

Но ведь при этом будет сильный штраф на производительность.

Или писать на пурсе или хаскель

ну в проде вырезать проверки легко

этоже только для девелопа и теста

ну пурса и хаскель не имеют из коробки refinement/dependant типов(в 8 знаю что чтото появилось) и там тоже надо иногда использовать динамические доказательства

ну пурса и хаскель не имеют из коробки refinement/dependant типов(в 8 знаю что чтото появилось) и там тоже надо иногда использовать динамические доказательства

Ну куда лучше чем тс и флоу

Ну оно и понятно. ТС и флоу это же больше инженерные\прикладные вещи. Т.е. баланс между эффективностью и простотой в пользу простоты. Если сделать сиситему типов и механику аналогичную Haskell то просто никто не будут использовать ни ТС ни флоу.

да конечно лучше я говорил к тому что не стоит зацикливатся только на статических доказательствах - надо уметь пользоватся и всем арсеналом динамических. в идеале бы конечно еще чтобы языки помогали использовать и то и то и переходит с одного на другое более менее бесшовно

Динамических языков не существует как мат модель

И полных непротиворечивых формальных систем, это ж не повод ничего не делать)

Но ведь при этом будет сильный штраф на производительность.

тык это в дев-мод только

Запилил брейнфак на свободных монадках)))

Ну оно и понятно. ТС и флоу это же больше инженерные\прикладные вещи. Т.е. баланс между эффективностью и простотой в пользу простоты. Если сделать сиситему типов и механику аналогичную Haskell то просто никто не будут использовать ни ТС ни флоу.

Ну, почему. Вон в скале же довольно развитая система типов. Но никто не заставляет все использовать. Бери только то, что тебе надо

Ну, почему. Вон в скале же довольно развитая система типов. Но никто не заставляет все использовать. Бери только то, что тебе надо

Сравните число разрабов на скала и на js

Сравните число разрабов на скала и на js

Думаешь, это из-за системы типов ?)))

Думаешь, это из-за системы типов ?)))

Не только из-за неё. В целом из-за концепции языка. Чтобы начать писать вменяемый код необходимо очень много прочитать не относящегося непосредственно к scala. Я по себе сужу (нормальный код пока не могу писать)

ERROR: S client not available

Ну оно и понятно. ТС и флоу это же больше инженерные\прикладные вещи. Т.е. баланс между эффективностью и простотой в пользу простоты. Если сделать сиситему типов и механику аналогичную Haskell то просто никто не будут использовать ни ТС ни флоу.

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

Человек ленивая сволочь, и берет то, что дешевле или проще, даже если это вредно и не полезно

Не только из-за неё. В целом из-за концепции языка. Чтобы начать писать вменяемый код необходимо очень много прочитать не относящегося непосредственно к scala. Я по себе сужу (нормальный код пока не могу писать)

Если бы скала поддерживалась на равне с JS в браузерах, то и распределение было бы другое. А так мы сравниваем теплое и соленое

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

В итоге сообщество разделится на тех кто использует Типизацию (с большой буквы) и тех кто лабает в динамике не задумываясь об этом вообще. Ну это моё мнение.

Да, это вполне логично)

Человек ленивая сволочь, и берет то, что дешевле или проще, даже если это вредно и не полезно

Дешевле понятно как оценить, а вот пользу/вред?

Если бы скала поддерживалась на равне с JS в браузерах, то и распределение было бы другое. А так мы сравниваем теплое и соленое

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

лабать в динамике !== не задумываться вообще

лабать в динамике !== не задумываться вообще

Я не утверждал этого. Речь о том, что многие просто не будут пользоваться типизацией потому, что это уж слишком усложняет

Кстати брейнфак это что-то типа ленты Тьюринга

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

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

А потом уже постепенно приходило понимание

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

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

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

https://trends.google.ru/trends/explore?q=typescript%20react,flow%20react,javascript%20react

вот так корректнее

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

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

и может ли он вообще так делать?

Надо популяризировать типы как-то.

Аппелировать к хип-молодежи типо меня что это здорово, круто, и если смузи пьешь то хотя бы флоу должен использовать.

А там мб сядут за нормальные языки.

А там мб сядут за нормальные языки.

дык потом проблема, что либо на хаскеле, либо и флоу норм

Ну Флоу это уже не без типов.

Лучше с флоу чем без флоу.

ну я про “нормальные языки"

Нормальные языки это Джава там.

Кресты.

Шарп.

эу

ща выдохну