например итераторы

Я раньше пробрасывал пайплайн tsc | babel, но с 2.1 отказался от этого. Сразу стало намного быстрее компилироваться, в целом рад.

это вряд ли

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

http://babeljs.io/docs/usage/caveats/#classes

да, как и в тс

в тс норм воркераунды

нет

тс даже не пытается

Хотя в итоге я, конечно, наркоманию с наследованием от массива просто выпилил :)

А мне нравится такой способ

Бабель у меня не мог от массива отнаследоваться правильно (≡ шоб хоть как-то работало), а tsc влёгкую.

Вместо пресета впиливай те возможности, которыми реально пользуешься. Там при транспиляции классов эта функциональность ломается

А мне нравится такой способ

Наследоваться?(

Наследоваться?(

Ну это же не расширение прототипов

Вообще с символами в язык подвезли много фич чисто для такой задачи

Да я скорее про то, что наследование ну очень редко (почти никогда) нужно

Ну я ж не говорю, что я их везде рассовываю)

Ну я ж не говорю, что я их везде рассовываю)

Ну почти никогда, это когда тебя инфраструктура вынуждает, как реакт компонент например

https://www.keithcirkel.co.uk/metaprogramming-in-es6-symbols/ вот тут хорошо рассказывают про символы

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

Ну почти никогда, это когда тебя инфраструктура вынуждает, как реакт компонент например

Вот только хотел про него написать ?

> @chicoxyzzy в большинстве случаев это будет лучше оптимизироваться, чем композиция с чего бы?

потому что можно почти 1 в 1 транслировать

и замыканий меньше в 100500 раз

экономия памяти

поиск по цепочке прототипов очень быстрый

и тд и тп

транслировать что во что?

о каких замыканиях речь?

поиск по цепочке прототипов быстрее чем лукап свойства?

быстрее чем фабрики

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

mraleph и прочие ж

чо рассказывать, сам все знаешь

о замыканиях, которые внутри этих фабрик бесконечных

ну я не согласен с утверждением, в общем

может хоть пример приведешь, что быстрее чего

должно быть

неа

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

если даже и лучше оптимизироваться будет, то все равно не норм. При наследовании больше чем в 1 уровень нарушить принцип бабушки Барбары все проще и менее очевидно, а потом кому-нибудь захочется еще протектед делать, чтобы инкапсуляцию ломать

ой все

наследование убивает

забирай свои монадки

монадки сложна(

нет, конечно все мы знаем, что монады это всего лишь...)

burritos

если даже и лучше оптимизироваться будет, то все равно не норм. При наследовании больше чем в 1 уровень нарушить принцип бабушки Барбары все проще и менее очевидно, а потом кому-нибудь захочется еще протектед делать, чтобы инкапсуляцию ломать

Вообще изначально ты просто высказал дизреспект объектам, обратно совместимыми с нативными ? Речь даже не шла о каких-либо иерархиях))

class A extends Array уже иерархия :\

моноид в категории...

class A extends Array уже иерархия :\

Чем она отличается от React.Сomponent?)

моноид в категории...

эндофункторов :3

Чем она отличается от React.Сomponent?)

тем что без первого можно жить)

Да без жс в принципе можно жить, речь то не об этом)

без второго тоже

засекайте время, хаскелль уже в пути

class A extends Array уже иерархия :\

Ты не можешь поломать инкапсуляцию, наследуясь на один уровень от стандартных объектов)

Ну, точнее, сдуру то все можно

Абрамов сказал наследовать плохо

Ты не можешь поломать инкапсуляцию, наследуясь на один уровень от стандартных объектов)

но контракт сломать легко, переопределив стандартные методы)

делай как Абрамов сказал

Абрамов сказал наследовать плохо

Лишь бы не наследоваться

но контракт сломать легко, переопределив стандартные методы)

По возможности избегайте этого

По возможности избегайте этого

это да

делай как Абрамов сказал

Абрамоугодно??

Абрамов сказал наследовать плохо

и правда(

и шо теперь, наследоваться что ли(

shit happens

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

ну-ка отнаследуйся от двух классов сразу

ERROR: S client not available

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

в ts миксины завезли

в тс много говна, я знаю(

и ващет в жс всегда это можно было

ВНЕЗАПНО

и прям instanceof сможет, да?(

а это тут при чем?

это вообще не обязательно в ООП

и ваще у нас дак тайпинг лол

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

но instanceof нас обламывает

все что пишет код как Абрамов — это Абрамов

и прям instanceof сможет, да?(

const Storage = Sup => class extends Sup { save(database) { } } const Validation = Sup => class extends Sup { validate(schema) { } } class Person { } class Employee extends Storage(Validation(Person)) { }

но instanceof нас обламывает

инстансоф не является обязательным в ООП

ну ир есть нет, не сможет

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

инстансоф не является обязательным в ООП

ага, а в ОО обязательным являются только сообщения

Напомните, что надо сделать, чтобы ts-loader не трогал файлы, которые не участвуют в сборке?

Напомните, что надо сделать, чтобы ts-loader не трогал файлы, которые не участвуют в сборке?

files/include прописать правильно

в tsconfig

Пасиба

const Storage = Sup => class extends Sup { save(database) { } } const Validation = Sup => class extends Sup { validate(schema) { } } class Person { } class Employee extends Storage(Validation(Person)) { }

так instanceof Storage/Validation?

забудь об инстансоф

мне отвечают на instanceof, я отвечаю про instanceof

зачем тебе?

я в общем-то согласен, что он не нужен

и его использование это вредно

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

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

в дактайпинге не так проверяется

все что пишет код как Абрамов — это Абрамов

^

так instanceof Storage/Validation?

Symbol.hasInstance is a Symbol which drives the behaviour of instanceof