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)

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

Что ты там опять не осилил распарсить? Излагаю тебе аргументированно: нормальные люди (оопэшники к ним не относятся) давно научились строить динамические информационные системы без того, чтобы заранее прописывать кодом структуры данных с которыми система будет работать. Нынче одним из старейших таких систем стукнуло уже 50 лет. К сожалению жоопэшников опыт прогрессивного человечества обошел стороной, они все как один бездарны и массово не способны ни на что более, кроме того как приварить все структуры данных к коду и работать с ними исключительно в контексте своего убогого недоязычка.

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

Вот у тебя две структуры жсон с полями a, b, c и e, f, g тебе надо a=>e, b=>f, c=>g. Вопорс, нахера тебе тут нужно ооп с этими полями (a,b,c,e,f,g) гетторами, сетторами, типами и всей этой твоей дриснёй, когда нужно и значимо только a=>e, b=>f, c=>g независимо от того, что они из себя представляют?

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

это нубство на уровне первых шагов.

Так, ненуб, ты уже решил как дебажить все твои перевязанные зависимые друг от друга объекты с кривыми стейтами, которые ты старательно от всех закрыл? Я что-то не видел решения. Иди работай, мб поумнеешь. Нечего сидеть весь день на ЛОРе и херню собирать.

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

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

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

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

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

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

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

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

ооп нужно не тут.

Оооо, ты это даже признал.

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

Так зачем тебе интегрирование, когда надо умножать? Зачем решать простые задачи сложным способом? Зачем делать что-то через жопу, потому что все делают так, когда можно сделать нормально? Т.н. «Классическое» плюсовое оопэ - лишь это один из способов организации кода. Один из. Это не ультимативная херота, которая решает все. Вообще, на самом деле, пул задач для неё весьма узок, но из-за своего узколобия это тащат везде где можно. Зачем ты сюда припёрся и начал чем-то там размахивать - не совсем понятно.

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

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

Вполне допускаю, что даже в субд где-то есть пара классов. И даже в v8 точно есть больше чем пара классов. Только они не имеют никакого отношения к прикладной области.

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

Можно даже построить на них целый скриптовы язык, на котором решать прикладные задачи. О чём я, собственно, и писал выше.

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

ты ж сам сказал, что сложность данных надо описывать якобы заранее. так ты видишь ооп :)

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

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

alysnix ★★★
()