LINUX.ORG.RU

паттерны для правильного (и типизированного) JavaScript

 ,


0

3

Навеяно горячими стримами Мурыча. Я вот задумался: а ведь действительно, можно обойтись без TypeScript, если придумать удобные паттерны для JavaScript. Не хватает двух вещей:

  • Типизации на входе и на выходе, внутри тел функций и у констант она избыточна.
  • Интерфейсов. Для классов можно использовать наследование, но для объектов уже надо думать над валидаторами.

Без остального сахара можно обойтись.

Первое можно решить с помощью optional, как в Java. Можно написать один обработчик для всех типов (с методами getString, getInt и т. д.), или разные. Привязать к синглтону, чтобы мочь глобально отключать проверки в рантайме (например, по флагу в env). Так мы получаем удобные подсказки в редакторе и работающую проверку типов.

Вот с интерфейсами для Object / Array / Set / Map сложнее. Думаю, нужно поэкспериментировать с optional, чтобы на выходе тоже дёргались типизированные методы.

А чтобы получить типизированные интерфейсы для классов, просто наследуемся от типизированного родителя: где на входе и выходе методов optional, а тело просто делает throw new Error('not implemented').

Теоретически, это всё можно запихнуть в библиотечку. Но не знаю, дойдёт ли у меня до такого, я очень задолбался и могу разве что на своих проектах поэкспериментировать, когда (хз когда) такая возможность представится. Может, кто из ЛОРовцев осилит. Ну и высказывайте свои идеи, чтоб собрать их в кучу.

Хочется изобрести рабочую методологию для написания больших и запутанных проектов, а не использовать костыли вроде TypeScript. Это не кажется невозможным. Или может она уже есть, а я о ней не знаю? Из известного нравится подход Тимура Шемсединова: чистый JS с *.d.ts декларациями. Но это не совсем то.

★★★★

Последнее исправление: InterVi (всего исправлений: 2)

Ответ на: комментарий от Nervous

Вот если после нового стандарта с type annotations станет не нужным ts — то да, норм. Но ведь мелкософт этого не допустит, они не для того предложениями спамят.

InterVi ★★★★
() автор топика
Ответ на: комментарий от Obezyan

Javascript - это язык

JavaScript — это торговая марка, принадлежащая Oracle. Языком называют только потому, что так исторически сложилось.

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

Тред не про макак, а про соображающих программистов. Его читать надо, прежде чем своё сверхценное мнение постить.

InterVi ★★★★
() автор топика
Ответ на: комментарий от InterVi

Языком называют только потому, что так исторически сложилось.

@

Тред не про макак, а про соображающих программистов.

Выберите что-то одно. У Вас каша в голове.

JS как язык появился минимум на год раньше первой спецификации Ecma 262, которая и была призвана стандартизировать уже созданный JS. А ECMAScript является компромиссным названием для всех участвующих в создании спеки и живёт только в документе.

Obezyan
()
Ответ на: комментарий от crutch_master

«типизация во время исполнения» - это «пришел на рыбалку - удочки забыл».

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

чтобы на рыбалку прийти уже с удочками.

alysnix ★★★
()
Ответ на: комментарий от InterVi

если после нового стандарта с type annotations станет не нужным ts — то да, норм

И вместо компилятора TS со всей этой статической байдой, которая на хрен не упала во время исполнения, будет разбираться браузер? Он что, ещё недостаточно жрёт и тормозит? %)

Лучше пусть будет отдельно и опционально, ящетаю.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 2)
Ответ на: комментарий от InterVi

можно добавить сахар только для редакторов

Так всё равно ведь будет два диалекта — со статическими типами и без. И всё равно надо будет транспилировать засахаренный исходник в диетический, чтобы браузер его мог понять. А значит, всё равно нужен отдельный канпелятор.

Или ты как-то по-другому себе представляешь светлое будущее без тупоскрипта?

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от alysnix

«типизация во время исполнения» - это «пришел на рыбалку - удочки забыл».

Строго говоря, она в любом случае во время исполнения или компилятора, или интерпретатора.

чтобы на рыбалку прийти уже с удочками.

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Nervous

И вместо компилятора TS со всей этой статической байдой, которая на хрен не упала во время исполнения, будет разбираться браузер?

Никак. Стат байда обнуляется в рантайме.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

стат байду надо прокачать по сети и пропарсить интерпретатором если ее добавят в js

man минификация

если чистая интерпретация, то это лишние усилия

Если это хинты для стат типизации, то там нет никаких условий в рантайме, да и нахрена они нужны.

crutch_master ★★★★★
()
Ответ на: комментарий от alysnix

У тебя есть класс x полями f1,f2,f3.
В рантайме надо: вывести список полей с типами, установить значение поля по имени (с валидацией типа), вывести значение поля по имени.
Суть в том, что все должно работать без лишних телодвижений, т.е. список полей есть только в одном месте - в коде класса, его набирание несколько раз считается зашкваром. Да и вообще любые лишние правки - автозакшвар.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

ну напишите на с++ валидаторы и устанавливайте ими поля с++ обьекта. в чем проблема? зачем иметь полное представление о структуре в рантайме, если не для работы под отладчиком? в рантайме нужны уже адреса и смещения полей относительно адреса экземляра, а не какие-то там имена полей. экономим и на памяти и доступаемся до значения поля за одну машинную команду.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

Проблема в том, что у тебя си++ головного мозга. Как пхпшники не думают вне контекста пхп, ты не думаешь вне контекста си++.
Делая так, ты делаешь по сути свой жс, кек.

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

Для рефлексии. Но ты никогда с такими вещами не работал, не понимаешь как это и где это можно применить.

в рантайме нужны уже адреса и смещения полей относительно адреса экземляра

Сделай самый тупейший круд для вебни, где поля в сохраняемый в бд объект будут устанавливаться по смешению из хттп гет запроса. И в жсон тоже будут выводиться смещения вместо названия полей, кек.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Для рефлексии. Но ты никогда с такими вещами не работал, не понимаешь как это и где это можно применить.

прицепи к с++ классу массив с именами, типами и смещениями полей … и получится твоя незаменимая рефлексия. если тебе оно так надо.

«имена полей», это всего лишь дополнительная человекочитаемая инфа, и не более. она ничего нового не добавляет к программе, кроме отображения - «имя-> смещение тип». если вы это там называете волшебством рефлексии, то это смешно.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от crutch_master

У тебя есть класс x полями f1,f2,f3.

В рантайме надо: вывести список полей с типами

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

зашквар

автозашквар

У меня таки складывается такое впечатление, что весь ваш ООП — это один сплошной самоавтозашквар %)

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 2)
Ответ на: комментарий от Nervous

У меня таки складывается такое впечатление, что весь ваш ООП — это один сплошной самоавтозашквар

Предлагаю называть подобное: «Лоскутное ООП в C++».

Вообще, давайте снизим ожидания насчёт уровня их понимания, мой комментарий вообще предпочли проигнорировать ибо ответить по существу нечего, что уж об остальном говорить. Это печально.

Obezyan
()
Ответ на: комментарий от Nervous

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

у них тупо прибить гвоздями имя в запросе, имя в обьекте и имя в базе - называется продвинутым стилем программирования, с использованием «мощи» рефлексии. на си++ такое просто так не напишешь, угу.

alysnix ★★★
()
Ответ на: комментарий от alysnix

похоже вы не поняли ответа. :)

Вы не дали ответ, вы слились.

Ответ на первую часть: A special kind of hell

Ответ на вторую часть: true и false.

Примите мои соболезнования, я думал Вы - синьор.

Obezyan
()
Ответ на: комментарий от Obezyan

Ответ на вторую часть: true и false.

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

спецэффекты зависят от реализации. изучать все возможные реализации с/с++ мне вот тоже неинтересно. и обсуждать неинтересные вопросы - неинтересно вдвойне.

можно придумать 38 битный комп и упороться там со спецэффектами. но это тоже неинтересно.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

это всего лишь дополнительная человекочитаемая инфа

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

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

Так почему до сих пор не внедрили?

она ничего нового не добавляет к программе

Если ты не умеешь чем-то пользоваться, то это таки ничего не значит.

то это смешно

Смешна тут только твоя убогость.

crutch_master ★★★★★
()
Ответ на: комментарий от Nervous

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

А не насрешь на ооп, так и будешь делать классы ради одной строчки кода.

У меня таки складывается такое впечатление, что весь ваш ООП — это один сплошной самоавтозашквар %)

Так я и не против.

crutch_master ★★★★★
()
Ответ на: комментарий от alysnix

прибить гвоздями имя в запросе

Ну можешь не прибивать, делать 20-30 правок вместо одной. В нормальном ынтерпрайзе может быть нормой, когда добавление одного поля в апи требует от двух недель работы. Дрочите, я не против.

на си++ такое просто так не напишешь

Так ты написал?

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

тебе что надо? чтобы все имена полей в классах, базе данных, жысонах конфигов, и запросов по сети совпадали?

на с++ можно намутить любое. только такое сделать никто в здравом уме не даст. это просто порушит всякие там соглашения об именах в классах, протоколах обмена, форматах хранения и тепе.

alysnix ★★★
()
Ответ на: комментарий от crutch_master

Ну можешь не прибивать, делать 20-30 правок вместо одной.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

Чтобы что? Имена не используются, не пишутся руками, никто не пишет код, никто не пишет в код руками поля. Это не нужно. Это порождает лавину правок в будущем. Проект станет невозможно поддерживать в конечном итоге. Если ты хочешь другие название полей, делается мапер, в который пишется, какие поля нужны/не нужны, какие на какие заменить и ты работаешь с другими именами, как работает любая другая внешняя система.
Ты застрял на уровне где

x.a = y.a;
x.b = y.b;
...
и не понимаешь вообще ничего за гранью этого.

тебе что надо? чтобы все имена полей в классах, базе данных, жысонах конфигов, и запросов по сети совпадали?

Я забыл сказать, что кроме имён и типов хорошо было бы добавить еще произвольную метаинформацию, (aka аннотации) но тебе и так дурно стало.

на с++ можно намутить любое.

Да, можно. Жс, яву, сисярп, пистон и много еще чего.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от alysnix

Я лишь привёл пару примеров на Ваше утверждение о том что в С++ все хорошо с типами.

Конечно, если писать под одну архитектуру и на подобные вещи говорить «мне это не интересно», то наверное можно оставаться в мире розовых указателей и верить что все хорошо.

Obezyan
()
Ответ на: комментарий от crutch_master

Проект станет невозможно поддерживать в конечном итоге.

Вы сейчас описали довольной большой кусок С/С++ проектов. Мне иногда кажется, что у многих программистов на С и С++ какая-то ментальная травма от указателей и смещения адресов в памяти.

Obezyan
()
Ответ на: комментарий от Obezyan

ментальная травма от указателей и смещения адресов в памяти.

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

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

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

какая может быть ментальная травма от указателей?

Такая что надолго зарываясь в уровень адресации памяти программисты зачастую застревают в этой «области видимости» и не могут осознавать ничего на вышестоящем слое. Отсюда и максимально ублюдские архитектурные решения в проектах и Ваше непонимание того что пишет @crutch_master

Obezyan
()
Ответ на: комментарий от Obezyan

Чтобы что? Имена не используются, не пишутся руками, никто не пишет код, никто не пишет в код руками поля. Это не нужно. Это порождает лавину правок в будущем. Проект станет невозможно поддерживать в конечном итоге. Если ты хочешь другие название полей, делается мапер, в который пишется, какие поля нужны/не нужны, какие на какие заменить и ты работаешь с другими именами, как работает любая другая внешняя система.

я пытаюсь понять, что пишет этот чел. видимо в этой развесистой чепухе он имеет ввиду классическую инкапсуляцию, где «никто не пишет руками поля». и что делают «мэпперы».

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

поля это в общем смысле - внутренний стейт экземпляра класса. и прямой к нему доступ делает всю систему подобных классов хрупкой.

то есть никто не применяет мэпперы, а применяют процедурный механизм доступа и модификации стейта.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от Obezyan

Он пытается объяснить что инкапсуляция нужна не везде и не всегда

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

а у него их нет. у него все основания - «я писатель - я так пишу!»

в си++ для поддержки инкапсуляции и работы с ней введены спецификаторы видимости, френды, и возможность залезть через наследование. то есть полный фарш и непонятно что еще нужно. сделано это не с бухты-барахты.

он что предлагает? открыть все внутренности и сделать какие-то «мэпперы»…ааааахахаха. вот тут проекты и повалятся.

alysnix ★★★
()
Ответ на: комментарий от Obezyan

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

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

любое изменение стейта снаружи должно сохранять инварианты класса. то есть экземляр должен быть корректным до начала некоей операции и по выходу из нее.

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

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

это прямое нарушение инкапсуляции.

Именно так, и иногда она просто необходима. Поэтому я и написал что правильное, идеальное ООП существует лишь в книгах.

ООП не святой грааль, а просто один из подходов в разработке программ.

Obezyan
()
Ответ на: комментарий от Obezyan

и иногда она просто необходима

иногда, это когда? есть только одно иногда, железно нуждающееся в «интроспекции». это отладка под дебаггером. для этого тот же с/с++ закидывает всю инфу для таких вот «рефлексий» в обьектники, отчего исполняемый файл вырастает раз в 10. но это особый случай. мы его не обсуждаем.

alysnix ★★★
()