разве

Да

чет мне кажется declare в коде юзать как-то пахнет

я так пытался чужой модуль описать

чет мне кажется declare в коде юзать как-то пахнет

так это не в коде)

Да какая разница

я так пытался чужой модуль описать

там type не прокатил

Это одинаковые возможности

там type не прокатил

Почему?

http://www.typescriptlang.org/play/#src=declare%20function%20x()%3A%20string%0D%0Adeclare%20namespace%20x%20%7B%0D%0A%20%20export%20const%20prop%3A%20string%3B%0D%0A%7D%0D%0A%0D%0Ax.prop%0D%0Alet%20y%20%3D%20x()%0D%0A#src=type%20X%20%3D%20()%20%3D%3E%20string%20%26%20%7B%20prop%3A%20string%20%7D%3B%0D%0Adeclare%20const%20x%3A%20X%3B%0D%0A%0D%0Ax.prop%0D%0Alet%20y%20%3D%20x()%0D%0A

не работает

Короче ладно, расскажите как вместе с классом рядом экспортить интерфейсы/типы без неймспейса

http://www.typescriptlang.org/play/index.html#src=declare%20interface%20X%20%7B%0D%0A%20%20()%3A%20string%2C%0D%0A%20%20prop%3A%20string%2C%0D%0A%7D%0D%0A%0D%0Adeclare%20var%20x%3A%20X%0D%0A%0D%0Ax.prop%0D%0Alet%20y%20%3D%20x()%0D%0A

Это одинаковые возможности

покажи плиз

а без namespace?

^

http://www.typescriptlang.org/play/index.html#src=declare%20interface%20X%20%7B%0D%0A%20%20()%3A%20string%2C%0D%0A%20%20prop%3A%20string%2C%0D%0A%7D%0D%0A%0D%0Adeclare%20var%20x%3A%20X%0D%0A%0D%0Ax.prop%0D%0Alet%20y%20%3D%20x()%0D%0A

☝?

http://www.typescriptlang.org/play/index.html#src=declare%20interface%20X%20%7B%0D%0A%20%20()%3A%20string%2C%0D%0A%20%20prop%3A%20string%2C%0D%0A%7D%0D%0A%0D%0Adeclare%20var%20x%3A%20X%0D%0A%0D%0Ax.prop%0D%0Alet%20y%20%3D%20x()%0D%0A

лол

Что?

Что именно?) Да, я вроде в процессе типизации рамды, жить можно) Но флоу форсит некоторые практики ради выводимости типов, из-за которых ряд методов рамды просто больше не используются, поэтому проблем меньше ¯\_(ツ)_/¯

типа не писать в pointfree? т.е. те же самые практики, что и тс или какие-то другие?

потому что внутри у меня где-то path<string>, а где-то converge(...) as any, а снаружи вот та ф-ция, которая использует все вот эти другие маленькие ф-ции (где я типы подкостыливал), она as any и вот толку тогда от этого

Ну я короче так в ts и разочаровался ?

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

^ вот отличается ли флоу в этом плане?)

В каком именно?

в плане предназначенности языка для типизации таких функциональных штук

ибо тс не вывозит в этом плане, возможно, что и флоу тоже

типа не писать в pointfree? т.е. те же самые практики, что и тс или какие-то другие?

Нет, тс такое не форсит, а зря кстати Просто сдерживается уровень абстракции не позволяя городить фабрики фабрик фабрик https://flow.org/en/docs/lang/refinements/ И предыдущие две статьи

^ вот отличается ли флоу в этом плане?)

В этом плане нет

тут ZeroBias скидывал статейку про HOC в ts годно было

так что тс вполне вывозит

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

так что тс вполне вывозит

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

Я чёт не понял о чем речь

об использовании рамды + ts / flow

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

ramda — это хелперы для нормальных adt из fl

Я чёт не понял о чем речь

Просто то что типы некоторых функций рамды невыразимы без упрощений

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

ну я не от хорошей жизни рамду хочу использовать)

А почему? Кто-то заставляет?

Либо код в проекте не оч

Тогда хелперы рамды прям на ура заходят

А почему? Кто-то заставляет?

а что использовать вместо?

Писать код?

т.е велосипеды свои?) не понимаю

просто нехватает каких-то элементарных вещей, функций

Например?

ну вот все то, что есть в рамде, большинство из этого мастхев

а что использовать вместо?

Условно — вместо того, чтобы делать pluck, должна быть структура, для которой не нужно делать pluck и можно обойтись хорошо типизированными функциями рамды и жс

ну вот все то, что есть в рамде, большинство из этого мастхев

Не верю

Хорошо типизированные — это те, которые не меняют структуру типа и не путешествуют по его дереву

понятно, спасибо

Коллеги, вопрос, есть реальная необходимость такого поведения или это бага TS? export type Foo = { x: number; } export class A<T extends Foo> { public m: T; constructor() { this.m = {x: 1}; } } Error:(89, 9) TS2322:Type '{ x: number; }' is not assignable to type 'T'.

При этом при передаче в качестве аргумента все ок export type Foo = { x: number; } export class A<T extends Foo> { public m: T; constructor(m: T) { this.m = m; } } new A({x: 1})

у меня вроде такое работало

хз, по моему логично, ты пытаешься в неизвестный заранее тип, но при этом конкретный в реализации, запихнуть литерал объекта, который не факт что соответстует этому типу

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

Ээм а по мне выглядит как бага

Ну и в итоге один и тот же литерал передаю

хз, по моему логично, ты пытаешься в неизвестный заранее тип, но при этом конкретный в реализации, запихнуть литерал объекта, который не факт что соответстует этому типу

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

@Sirian обсудим?)

Это не "не известный заранее тип", это дженерик с нижней границей в { x: number }

ну типа неизвестно, что T будет {x: number}

Ты же это декларировал?

с чего бы ему думать что это правильно

ну типа неизвестно, что T будет {x: number}

T extends Foo же

Другое дело, что это структурное соответствие, и тс в него не может

это ж дженерик, он может чем угодно быть

ERROR: S client not available

Тогда объясните, чем декларация локальный переменной от декларации аргумента отличается

Другое дело, что это структурное соответствие, и тс в него не может

В flow с таким проблем нет

а, все, я чет не обратил внимания на extend

В flow с таким проблем нет

Это хорошо, но хотелось бы найти ссылку на описание подобного поведения

а, все, я чет не обратил внимания на extend

Кстати, да, возможно. Только пока не могу формализовать причину. Но вроде выглядит логичным, что литерал должен быть унаследован от {x: number}, а не является им.

Другое дело, что это структурное соответствие, и тс в него не может

вроде TS как раз именно в структурное и может, разве нет?

Нет

let m: Foo = {x: 1}; так все нормально.

Ну это ты явно привязываешь тип

вроде TS как раз именно в структурное и может, разве нет?

Тс изначально только в номинальное умел. Сейчас вероятно ситуация может быть получше, но как видно, не до конца

он говорит и Foo not assignable to T в таком случае

как то так

Тс изначально только в номинальное умел. Сейчас вероятно ситуация может быть получше, но как видно, не до конца

а можно ссылку или пример? у меня ощущение что я запутался в терминах

Type compatibility in TypeScript is based on structural subtyping. Structural typing is a way of relating types based solely on their members. This is in contrast with nominal typing.

а можно ссылку или пример? у меня ощущение что я запутался в терминах

https://flow.org/en/docs/lang/nominal-structural/

Либо мы что-то не так решили, либо всё же не до конца структурное

блэ вот ща совсем непонятно стало export type Foo = { x: number; } export class A<Foo> { public m: Foo = {x:1};

говорит {x:number} нельзя присвоить Foo

Возможно там бага. Но в TS вполне себе структурное

А если заменить type на interface?

то же самое

Стоп!

class A<Foo>

это уже не тот же самый Foo

Кстати да

оп, точн

вполглаза с работой не получается))

это уже не тот же самый Foo

А я попался)))

https://basarat.gitbooks.io/typescript/content/docs/tips/nominalTyping.html

Ну это примеры того, как заставить TS использовать номинальную типизацию вместо структурной, если очень нужно

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

Ну он по ходу просто тип не вывел