Мда, чуток тупой пример, и все же тска будет считать две разные модельки одним классом

Да, будет. Но проблемы у тебя не в этом )

Да, будет. Но проблемы у тебя не в этом )

я знаю) Но это уже другой топик, тут просто мой неудачный пример

Да, будет. Но проблемы у тебя не в этом )

Это не делает подобное поведение менее проблемным)

Ну, если классы будут отличаться по структуре, то данное поведение будет доставлять чуть меньше проблем

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

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

Угу, разные языки, разные типизации

Да, будет. Но проблемы у тебя не в этом )

https://github.com/Vincit/objection.js/blob/master/examples/express-ts/src/models/Animal.ts Ну вот так автор решает это, мне нравится) *знаю что уже все, структуры разные, это уже не к топику*

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

type North = { readonly type: unique symbol; } type South = { readonly type: unique symbol; } type East = { readonly type: unique symbol; } type West = { readonly type: unique symbol; } type Direction = North | South | East | West

вполне симпатишно

вот так выкрутиться можно

а термы какие?

а термы какие?

о чём речь?

ну значения

подходящие под этот тип

type North = { readonly type: unique symbol; } type South = { readonly type: unique symbol; } type East = { readonly type: unique symbol; } type West = { readonly type: unique symbol; } type Direction = North | South | East | West

Не, через типы это иной кейс) Через типы понятное дело что вот так можно, классы просто снимают бойлерплейт данного приема, и на шаг ближе к нормальной алгебраической сумме типов

Не, через типы это иной кейс) Через типы понятное дело что вот так можно, классы просто снимают бойлерплейт данного приема, и на шаг ближе к нормальной алгебраической сумме типов

До недавнего времени было нельзя )

До unique symbol

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

ну значения

Это хороший вопрос

А если выкинуть из TS все то, что есть во Flow, что останется? Их вообще можно сравнивать?

conditional types как миниму

Это сахар

Это сахар

И даже infer дл return type?

в флоу не нужен infer для return type)

В флоу есть $Call для того чтобы получать это непосредственно

Насчёт conditional types вот у меня конкретный кейс

эти $Call вообще заставляют меня задуматся об чистом js ;)

https://github.com/zerobias/effector/blob/master/packages/effector/index.js.flow#L112 этот тип разворачивает контейнер Store и оставляет его дженерик, но если это не Store то тип возвращается как есть

(госпади как же тяжело читать код без отступов, просто нифига не понимаю, где там куда вложенно)

(госпади как же тяжело читать код без отступов, просто нифига не понимаю, где там куда вложенно)

+

const foo = createStore(0) const bar = createStore('bar') const baz = merge({foo, bar, kek: 0}) Тип baz будет Store<{ foo: number, bar: string, kek: number, }>

Тип foo соответственно Store<number>, который был развернут по условию)

Воот. Собственно от condition types хотелось бы тоже ожидать чего то хотя бы подобного

Раз уж замутили для этого аж отдельный синтаксис

(госпади как же тяжело читать код без отступов, просто нифига не понимаю, где там куда вложенно)

Там есть отступы.

Раз уж замутили для этого аж отдельный синтаксис

а явную вариантность всё ещё не хотят

потому что cryptic

Ппц))

https://youtu.be/etKOc80-cw0?t=42m5s

интересная реализация

TS тупит жестко, а flow подсказывает там, где бы я даже не ожидал его увидеть

https://reasonml.github.io/docs/en/if-else.html

а это еще интересней

Да, я к этому на самом деле и клонил

Номинальная типизация — мост между жс и sum type из ризона

Как они связаны?

class A {} class B {} type AB = A | B

Всё тебе отдельно надо пояснять))

Только это делается обычно через тэги, а не классы

Обычно да

есть какие-то вменяемые реализации стэйт машины на ts?? чтоб с колбэками и сохранением-восстановлением состояния?

Обычно да

Следующий шаг — заметить что это равносильно но быстрее описывается через классы

Не знаю, чем это быстрее

Чем тегами

Это не быстрее, это так же

class A {} class B {} type AB = A | B

Давай на конкретном примере)

Давай пример

class A {} class B {} type AB = A | B

Всё тебе отдельно надо пояснять))

type AB = | { t: 'A' } | { t: 'B'}

У меня если что готовые конструкторы

Здесь я вижу только декларацию

Нет у тебя как раз конструкторов

Их еще отдельно написать придется

new A даёт новое значение типа A

Ок, new A() против { t: 'A' }

против const a = () => ({ t: 'A' })

Зачем?

Сорян, одного тайп левела маловато

Если тебе нужна такая функция, то в таком случае и с классми нужно будет () => new A

Нет, зачем? Конструктор уже есть

Потому что писать new A ничем не лучше, чем писать { t: 'A' }

Это называется буквоедство вот сейчас тут упираться и утверждать что не видишь никакой разницы

Я понял твою позицию, меня подобная уравниловка не устраивает

1. На практике я не вижу разницы 2. Причем здесь ризон? Там как раз нет конструкторов

Начинаешь понимать

Ребят, а в какой среде разработки пишете на flow? В вебсторме у меня какая-то дичь происходит:

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

тоже самое и с ошибками, мега слоупочно

это я что-то криво настроил, или это просто криво реализован syntax highlight и прочее в webstorm'е?

export function fun<T extends {new(...args:any[]):{}}>(target: T) { return class extends target { newMethod(): SomeType { return SomeTypeConstructor<T>(this); }; }; } - кто знает, почему this is not assignable to T?

Ребят, а в какой среде разработки пишете на flow? В вебсторме у меня какая-то дичь происходит:

не пишу на флоу как раз по этой причине

инфраструктура у него говно)

просто шторм шибко умный, мейби лучше попробовать vscode?

по крайней мере в последних версиях с тайпскриптом там оке доке)

с тайпскриптом но не с флоу)

ну да)

просто шторм шибко умный, мейби лучше попробовать vscode?

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

Ребят, а в какой среде разработки пишете на flow? В вебсторме у меня какая-то дичь происходит:

vs code + lsp норм, шторм тут сильно отстаёт Все дальнейшие вопросы лучше в чат по флоу https://t.me/flowtype_ru

в ВСке писал c++ буквально 5 минут, а наебался на часы

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

"говнопродукты" кек

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

ну по крайней мере, с чатом ты точно прогодал)

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

вскод кстати исключение) сам к нему подходил скептически, особенно после общения с вижуал студией образца 2008 года

vs != vscode

да, просто там они экплуатируют бренды майкрософта, вижуал студия, интеллисенс

они вообще зря назвали его vscode, сразу негативные ассоциации с vs

и всякое уг, хотя ничего общего с этим всем вот нету

дада