Comments 21
Когда примут, то на классах уже писать никто не будет
<sarcasm>.... и php наконец похоронят?</sarcasm>
Ага, а с появлением авиации автотранспорт тоже уже не используется.
Когда примут, то на классах уже писать никто не будет
уметь?
А вообще знаковый комментарий, характеризующий. Если перевести с русского на русский:
я не знаю ООП и не понимаю, где его нужно использовать
UPD: а ещё смешнее, что незнание (-- сила) ООП внезапно находит поддержку среди комментаторов -- комментарий не только минусовали. Не переключаемся, смотрим за развитием событий
Ну, знаковость вы сами дофантазировали. Непросто вообще разговаривать с человеком, который за тебя придумывает, что ты знаешь, а что нет. А потом же с этих мыслей смеется. Но это ладно.
Сложно отрицать направленность фронта в функциональную сторону.
Поэтому классы, которые 10 лет назад казались такими нужными в js, в скором времени могут остаться не у дел.
Прекратите называть процедурщину функциональщиной. Документация по haskell немного о другом.
Вы опять что-то за меня домыслили? Это я о доках по haskell, если что.
А по существу, вы же знаете, что много функциональных приемов есть в современном js: чистые функции, иммутабельность, меморизаторы и т.д.
Зачем попусту отрицать влияние функциональных языков?
Приведите хоть одну UI-библиотеку, построенную полностью на чистых функциях.
Я говорил о влиянии функциональных языков.
А вы мне говорите привести библиотеку полностью построенную на чистых функциях.
Как будто 1-е, обязательно вытекает из 2-го. Как будто слово "влияние" носит комплексный характер.
декоратор это обычная функция
Больше сахара богу сахара!
В python декораторы существуют и активно используются не первое десятиление. Что-то мне подсказывает, что паттерн жизнеспособен
Как фуллстек питон-жс - подтверждаю. Жизнеспособен. Но взамест сахара можно было бы добавить что-нибудь более полезное для организма :)
В целом то я не против ) Не очень понятно, откуда столко радости по поводу фичи, котрая, по сути, была в языке изначально. Ок, для свойств она стала доступна в полной мере с появлением сеттеров, геттеров и прочих defineProperty, но таки стоило ли оно затраченных усилий?
<душнила-мод> Паттерн в данном случае это функция высшего порядка, а декоратор это чистейшей воды сахар, чтобы красиво ее вызвать. </душнила-мод>
Норм, собрались мамкины фулстэки-питонисты обсуждать JS :)
Меня неистово радует, что в JS завезли аналоги f-строк, но не завезли format. Что превращает банальнейшую задачу подстановки значений в строку, подгружаемую извне, в рак мозга
А ещё я буквально вчера орал: в массивы завезли метод .at() -- аналог нашего слайса. Так вот, в строки завезли метод .charAt()
Во-первых, вас никто не заставляет писать с использованием нативных декораторов. Вы можете вообще на прототипах всё делать вместо классов, например)
Во вторых, чем плох, в конце-концов, сахар? Какая разница джуну на чём говнокодить говнокод? Для людей, которые умеют и знают сахар упрощает жизнь. Много людей использовали декораторы под Babel. Это куча кода после транспиляции. А так будет быстрее, компактнее и не нужны будут танцы с Babel.
Не хотите высокоуровневый сахар - идите к ассемблеру и его друзьям))
Некоторые фреймворки (в частности Nest) предлагают использовать декораторы в качестве аргументов конструктора для DI.
constructor(
@InjectModel(Group)
private readonly groupModel: typeof Group,
@InjectModel(GroupMessage)
private readonly groupMessageModel: typeof GroupMessage,
// другие зависимости...
) {}
Судя по всему новая спецификация не предполагает такого использования или я что-то не вижу?
Пока нет, но в экстеншенах есть - https://github.com/tc39/proposal-decorators/blob/master/EXTENSIONS.md#parameter-decorators-and-annotations
На самом деле декораторы ещё старше. Раньше они находились в другом репозитории: https://github.com/wycats/javascript-decorators/tree/master. И здесь первый коммит датирован 7 мартом 2015.
В тот же день было подано предложение о добавлении декораторов в TypeScript (где они появились в версии 1.5 от 20 июля 2015) https://github.com/Microsoft/TypeScript/issues/2249
А в stage 2 декораторы перешли в июле 2016 https://github.com/tc39/proposals/commit/97eb62f75be13e64341c6242f7291104c28a96f3
Итого для достижения stage 3 потребовалось более семи лет, из которых шесть пришлись на stage 2.
JavaScript декораторы наконец-то в Stage 3