Остановились буквально у черты

Перегрузка операторов там же

Иногда удобно

Особенно если не во внутреннем коде, а в экспоузимом апи, да.

А я бы не убирал. Если пишут новый язык, то почему не сделать перегрузку?

А я бы не убирал. Если пишут новый язык, то почему не сделать перегрузку?

Разве не усложнило бы это компилятор и сгенерированный код в разы?

Бандлы со всеми асершнами на каждый чих весили бы как с флоу рантаймом. И тормозили бы так же.

Разве не усложнило бы это компилятор и сгенерированный код в разы?

Какая разница до сложности компилятора?

Бандлы со всеми асершнами на каждый чих весили бы как с флоу рантаймом. И тормозили бы так же.

Чего? Зачем?

2 перегрузки - 2 разных имени для методов.

Да-да, туплю.

Только с any будет сложно.

2 перегрузки - 2 разных имени для методов.

Тогда публичные апи после транспайлинга не совпадали бы с исходниками.

Бандлы со всеми асершнами на каждый чих весили бы как с флоу рантаймом. И тормозили бы так же.

Флоу рантайм это лол, ты серьезно думал его применять?

Тогда публичные апи после транспайлинга не совпадали бы с исходниками.

И?

И?

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

Флоу рантайм это лол, ты серьезно думал его применять?

Я че, наркоман?

Я просто уточнил))

Хотя да, наркоман. Но не настолько.

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

Кавычки вокруг каждого слова

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

Чот взоржал немного)

class A{ f(): void f(a: number): void f(a?: number){} }

Спасибо, попробую, но жаль что реализация одна ((( ведь смысл этого патерна немного теряется

Только с any будет сложно.

Конфликты двух структурно похожих типов надо будет решать

Конфликты двух структурно похожих типов надо будет решать

Это да. Хотя можно заставить явно кастить как и в шарпе, к примеру.

Конфликты двух структурно похожих типов надо будет решать

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

Используете ли вы noImplicitAny в боевых проектах? Да – 22 ??????? 71% Нет – 6 ?? 19% Хочу включить с очередным рефакторингом – 3 ? 10% ? 31 people voted so far.

y меня весь strict true

Используете ли вы noImplicitAny в боевых проектах? Да – 22 ??????? 71% Нет – 6 ?? 19% Хочу включить с очередным рефакторингом – 3 ? 10% ? 31 people voted so far.

29% вы кто?

флоу?

29% вы кто?

Йа. Ts юзаю для подсказки типов там где мне это нужно

29% вы кто?

джаваскриптеры, очивидно же)

это провал

джаваскриптеры, очивидно же)

Лол

помимо noImplicitAny еще обязательно tslint no-any

джаваскриптеры, очивидно же)

А Тайпскрипт — не Джаваскрипт?

А Тайпскрипт — не Джаваскрипт?

Нет же

А Тайпскрипт — не Джаваскрипт?

нет конечно

Вот флоу где то там внизу на одном уровне с жс

Вот флоу где то там внизу на одном уровне с жс

Но флоу это вообще не язык, а статистический анализатор

Но флоу это вообще не язык, а статистический анализатор

А вот тс язык

вау, умеешь в инспектор?

Тс > жс Значит тс != Жс

вау, умеешь в инспектор?

https://www.typescriptlang.org/

лол

зашквар )

:D

лайк

извините, я все

если Kotlin начнет нормально в js, я забью на TS но пока до этого очень далеко

если Kotlin начнет нормально в js, я забью на TS но пока до этого очень далеко

Все равно извращение , имхо

Все равно извращение , имхо

для кого как, мне потом этот kotlin ой как во многих местах будет применяться это как на сегодня js везде, но только kotlin

Кек, про скалу сильно получилось ?

для кого как, мне потом этот kotlin ой как во многих местах будет применяться это как на сегодня js везде, но только kotlin

А в котлене есть аналог d.ts?

Ну навесные тайпинги для жс либ

А то так для вебчика и на сисярпе уже писать можно)

F#

А в котлене есть аналог d.ts?

есть

https://github.com/Kotlin/ts2kt

На жс, хехе

Но я понял, спасибо

что на жс?

ERROR: S client not available

Конвертер. Хотя похоже kotlin=>js таки, плохо я смотрел.

для кого как, мне потом этот kotlin ой как во многих местах будет применяться это как на сегодня js везде, но только kotlin

Просто зачем такой надрыв, уже nodejs на ts переходит(@nest_ru), а вы наоборот велосипед хотите )))

Чем вообще Котлин лучше Тс для веб разработки с точки зрения языковых фич?

Чем вообще Котлин лучше Тс для веб разработки с точки зрения языковых фич?

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

Чем вообще Котлин лучше Тс для веб разработки с точки зрения языковых фич?

Там есть val, а есть var. Мало где такое есть, почти нигде нет)

Дебажить такую хрень, просто ад

Просто зачем такой надрыв, уже nodejs на ts переходит(@nest_ru), а вы наоборот велосипед хотите )))

Что значит nodejs на ts переходит? (не набрасываю, я не понял)

Просто зачем такой надрыв, уже nodejs на ts переходит(@nest_ru), а вы наоборот велосипед хотите )))

шта

Что значит nodejs на ts переходит? (не набрасываю, я не понял)

Это гипербола, конечно, но в целом тренд. https://nestjs.com

Лол, тренд.

Так расскажи, что за тренд? Разрабатывать фреймоврки на ts?

ееее тренд

Это гипербола, конечно, но в целом тренд. https://nestjs.com

для ангулярщиков

в целом подход правильный, но только не для js

nest конечно говнище

втаскивать в жс тормозящее ооп

Лель

втаскивать в жс тормозящее ооп

а ты просто используй наследование а не композицию

Лель

а ты просто используй наследование а не композицию

просто ооп не нужно

Тут чел выше разложил по полочкам

просто ооп не нужно

Смотря в каком.

пасоны, ооп это же вообще моветон

только последние археоптериксы его юзают)

РЕФЛЕКТ МЕТАДАТА

во, нашел

Не соглашусь, после того как я понял главный профит наследования я теперь считаю наследование круче композиции (а множественное наследование еще лучше) При композиции каждое переопределение какого-то поведения требует создать объект. В итоге если у нас цепочка из 10 переопределений (например 10 хокков на реакт-компоненте) то на списке из тысячу объектов будет создано в сумме 10 тысяч объектов - а это тратится сpu на создание объектов, тратится в n раз больше памяти, и главное тратится в время на сборку всех этих объектов сборщиком мусора потом. Причем для хокков реакт-компонентов это не только время на создание объектов - это еще время на увеличения diff-а при рендере из-за n-кратного увеличения количества компонентов. А при наследовании для тысячного списка будет только тысячу объектов в рантайме - то есть, сколько бы раз бы не наследовались и добавляли или переопределяли методы, сколько бы цепочек переопределений бы не строили - да хоть тысячу хокков - в рантайме будет создан только один объект а не в n-раз больше. То есть наследование это механизм который позволяет вынести очень много работы в compile-timе и после того как я это понял я теперь не понимаю людей которые говорят что композиция лучше наследования

АААААЕЕЕ

Не соглашусь, после того как я понял главный профит наследования я теперь считаю наследование круче композиции (а множественное наследование еще лучше) При композиции каждое переопределение какого-то поведения требует создать объект. В итоге если у нас цепочка из 10 переопределений (например 10 хокков на реакт-компоненте) то на списке из тысячу объектов будет создано в сумме 10 тысяч объектов - а это тратится сpu на создание объектов, тратится в n раз больше памяти, и главное тратится в время на сборку всех этих объектов сборщиком мусора потом. Причем для хокков реакт-компонентов это не только время на создание объектов - это еще время на увеличения diff-а при рендере из-за n-кратного увеличения количества компонентов. А при наследовании для тысячного списка будет только тысячу объектов в рантайме - то есть, сколько бы раз бы не наследовались и добавляли или переопределяли методы, сколько бы цепочек переопределений бы не строили - да хоть тысячу хокков - в рантайме будет создан только один объект а не в n-раз больше. То есть наследование это механизм который позволяет вынести очень много работы в compile-timе и после того как я это понял я теперь не понимаю людей которые говорят что композиция лучше наследования

ндаааа