LINUX.ORG.RU

Как правильно сделать роутинг без фреймворков в TS?

 , ,


0

0

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

Контроллеры и методы представлены в следующем виде:

// базровый класс для всех контроллеров
class Controller {}

class Global extends Controller {

    // метод
    doStart(): object {
        return {
            status: 'ok',
            message: 'я работаю, всё ок',
        };
    }
}

Теперь нужно имея переменные controller: string и method: string вызвать нужный мне метод. Я затрудняюсь как. Кто знает — подскажите, пожалуйста :)

[hr]

Я пробовал сохранять методы в key-value массиве, чтобы метод можно было получить по строке. Вот так:

class Global extends Controller {
    _allow_method_list = {
        doStart: this.doStart,
    };
}

Этот это не подходит, потому что в этих методах почему-то нельзя использовать this, а это существенно и вообще знак что я что-то делаю не так.



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

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

Работает! Вот круто. А я упустил этот вариант.

Спасибо! :)

elonmusk
() автор топика

Кстати, а кто-нибудь ещё разрабатывал без фреймворков? Как у вас получилось сделать вызов методов контроллеров?

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

А зачем велосипедить свой фреймворк? Ведь именно свой кастомный фреймворк ты, в результате данного труда, и получишь. Но он будет значительно хуже по всем параметрам. Если только в научно/образовательных целях это имеет смысл.

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

Да, свой фреймворк. Не знаю, хуже ли. В фреймворке только то что мне нужно =)

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

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

В фреймворке только то что мне нужно

ну да, только одно колесо и только левая педаль, но мне хватает, а ещё я руль круглый сделал! во как удобно - можно на нем и сидеть и рулить. А ещё мне документация не нужна! :D

Я видел как разрабатывают на своих фреймворках в промышленности

у нас на работе свой фреймворк и ОРМ (живёт уже больше 10 лет, а если говорить о самых первых версиях на перле которые ещё были то это почти 18 лет) у этого есть как свои плюсы так и минусы, нужно их понимать. Писать своё имеет смысл когда под ваше задачу нет готовых решений которые вы можете удобно использовать хотя бы на этапе создания минимально жизнеспособного продукта (потом можно и переписать и так даже будет лучше ибо действительно будете знать что вам нужно и как нужно).

Noob_Linux ★★★★
()

К тайпскрипту хорошо подходят preact и typestyle. Суммарно 6kb оверхеда на страницу, зато писать на порядок приятнее чем ванилу. TS статически анализирует твой хтмл (tsx) и css (typestyle)

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

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

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

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

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

контроллеров

Таким говном не пользуюсь, но.

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

во-вторых, зачем ты тащишь все эти(контроллеров) птушные понятия к себе, если ты не пользуешься «фреймворками»?

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

Да и мой тебе совет - выкини это(TS) говно и возьми дарт, если тебе не требуется завязывание на дефолтную веб-инфраструктуру. Хотя даже на неё на нём можно завязаться. Он, конечно же, та ещё мертвечина, но декараторы в ts говно, типизация говно, вывод типов - говно, экосистема - говно. Есть более вменяемые альтернативы типа flow, но это ещё более мёртвая и протухшая параша, которая не развивается много лет. К тому же, если ты будешь допиливать тулинг(а ты будешь) - в ТС это делается без особых проблем(без учёта того, что авторы immutable-идиоты, которые родили тотально нелепый api и сами от него страдают), а вот с flow у тебя будет полная жопа, т.к. написан он на альтернативно-одарённом"языке".

К тому же, в дарте есть кодоген, лоадеры, observatory и вся фигня из коробки.

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

Я видел как разрабатывают на своих фреймворках в промышленности

https://habr.com/ru/company/infopulse/blog/330708/

В фреймворке только то что мне нужно =)

Но это ты делаешь сам, а мог бы сократить свой труд за счет одного (npm или yarn) install

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

но декараторы в ts говно, типизация говно, вывод типов - говно, экосистема - говно

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

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

с flow у тебя будет полная жопа, т.к. написан он на альтернативно-одарённом"языке".

Беда в том, что балбесы написали flow на Ocaml, тогда как могли бы это сделать на F# в рамках .Net Core. Это избавило бы от многих проблем.

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

тогда как могли бы это сделать на F# в рамках .Net Core.

Заменить одно птушное дерьмо на другое птушное дерьмо, да ещё и с анальным зондом? Да ты гений.

Это избавило бы от многих проблем.

Нет. Если только твои личные, религиозные проблемы.

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

Не идеально, но уж точно не говно.

Говно.

Получще некоторых статически типизированных языков

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

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

От этого декораторы там не появятся, хоть какая-то статика на уровне языка не появится(это вообще их манифесте написано).

Вывод типов там не появится - т.к. это не язык, а лишь обёртка над языком. Объясню подробнее. Дело в том, что в статическом языке компилятор не может НЕ ВЫВЕСТИ типы, а вот в прикрученной сбоку типизации - компилятор может вообще типы не выводить, там вообще компилятор работает отдельно от чекера.

Поэтому, как только чекер встречает сложное место - он просто кастит всё в any и всё - ошибок нет(вернее они есть, если эти типы потом попадают в более узкий контекст). И никто и никогда это чинить не будет.

Экосистема ts"а вся на жаваскрипте. Тайпинги все дырявые, особенно в контексте упомянутого тобою реакта. Их мало. Сам компилятор тайпскрипта - говно нелепое, к которому плагины/трансформеры писать запаришься. Какие-то попытки к порту бабель-плагинов идут, но всё это на зачаточном уровне, т.к. api говно, их компилятор не умеет в трансформеры - надо прикручивать левый лоадер для вебпака. А там свои проблемы. И эти вечные проблемы с путями в импорте.

Да, действительно. Для такого базового уровня ТС наиболее удобен, т.к. всё есть «из коробки» и может он(относительно) много. Но чем дальше в лес - тем больше он тебя тянет на днище.

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

оно их типизирует не лучше аналогов, а даже хуже

Каких таких аналогов? Flow? Когда он начнет развиваться, перестанет тормозить и обзаведется сравнимой базой d.ts-ок, то все закономерно переползут на него. А других аналогов я не наблюдаю

Поэтому, как только чекер встречает сложное место - он просто кастит всё в any и всё - ошибок нет

Можно пример? На практике не встречал. Вот в mypy сплошь и рядом, да.

Экосистема ts"а вся на жаваскрипте

Перепиши на Rust. Тебе пямятник при жизни поставят.

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

Херасе мало. Страничка на гитхабе не открывается. Проблем с тайпингами реакта не встречал — одни из лучших d.ts-ок. Вот в редуксе, да, бывает. Из-за того, что экшоны это строки, но и там это обходится костылями (хотя проще сменить редукс)

Сам компилятор тайпскрипта - говно нелепое, к которому плагины/трансформеры писать запаришься

Как по мне, бабель с вебпаком нелепы. Плагинные системы ради плагинных систем. Ставишь core, который и так не маленький, а оказывается, что надо сверху еще пару сотен пакетов доставить. Никто этим не запаривается, а просто накатывают сборку от васяна create-react-app и ему подобные. Не успеваешь опомниться, как твоя папка node_modules превратилась в черную дыру

Но чем дальше в лес - тем больше он тебя тянет на днище

Можно примеров из глубин леса? Меня пока все устраивает (кроме скорости компиляции)

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

Каких таких аналогов? Flow?

flow/dart и тысячи новоделов - всякие ризоны.

Когда он начнет развиваться,

Как быстро ты сменил методичку. Когда ts-параша начнёт в типы так же, как flow? С чего ты игнорируешь одно и пытаешься вещать о другом?

перестанет тормозить и обзаведется сравнимой базой d.ts-ок

Тормозит он не меньше тупескрипта, базой d.ts - они все говно, да и в контексте автора не нужны. Опять же, обосрался в одном - начал просто кидаться левыми тезисами из методички - зачем так делать?

то все закономерно переползут на него. А других аналогов я не наблюдаю

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

Можно пример? На практике не встречал. Вот в mypy сплошь и рядом, да.

Ну куда там тебе в практику. Мне лень вычленять из живого кода примеры на тыщи строк. https://bit.ly/2THlHJ3 - вот тебе типичный кейс, хелворд, а оно не осилил преобразовать тапл. И чем больше косвенности - тем большая и большая жопа.

Перепиши на Rust. Тебе пямятник при жизни поставят.

Причём тут этот мусор? Тебе говорят не про то, что js - это плохо, а про то, что ts - это просто убогая обёртка, с которой ты не можешь жить сам по себе. У тебя нет отдельной тс-экосистемы. Да, если какие-то тс-проекты, но это крохи.

Херасе мало.

Мало.

Страничка на гитхабе не открывается.

Просто гитхаб говно и там всякая мусорная попса.

Проблем с тайпингами реакта не встречал — одни из лучших d.ts-ок.

Тебе никто не говорит ТОЛЬКО про тайпинги самого реакта. Тебе говорят о всей экосистеме. Берёшь любую реакт-либу и молишься, чтобы там, где можно передать компоненты - ты не пошел патчить тайпинги, т.к. автор решил ограничиться базовыми типами.

Вот в редуксе, да, бывает. Из-за того, что экшоны это строки, но и там это обходится костылями (хотя проще сменить редукс)

Там везде говно.

Как по мне, бабель с вебпаком нелепы.

Показывай альтернативу.

Плагинные системы ради плагинных систем.

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

    function updateFunctionDeclaration(node: FunctionDeclaration, decorators: ReadonlyArray<Decorator> | undefined, modifiers: ReadonlyArray<Modifier> | undefined, asteriskToken: AsteriskToken | undefined, name: Identifier | undefined, typeParameters: ReadonlyArray<TypeParameterDeclaration> | undefined, parameters: ReadonlyArray<ParameterDeclaration>, type: TypeNode | undefined, body: Block | undefined): FunctionDeclaration;

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

Ставишь core, который и так не маленький, а оказывается, что надо сверху еще пару сотен пакетов доставить.

И? Это ничего не меняет. Захочешь что-то сделать - будешь юзать, альтернативы у тебя нет.

Никто этим не запаривается, а просто накатывают сборку от васяна create-react-app и ему подобные.

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

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

Не успеваешь опомниться, как твоя папка node_modules превратилась в черную дыру

Твои проблемы, как ваятеля низшего эшелона.

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

Можно примеров из глубин леса?

Всё очень просто. Берём банальную тс-попсу - декораты, о которых я тебе уже говорил. Дано - любой метод/поле, декоратор export. Задача - получить типы.

@export
filed = 123;

@export
f(a: number, b = 123) async {return new Obj(a, b);}

Любая более-менее сложная типизация.

Меня пока все устраивает (кроме скорости компиляции)

Ну как-бы тебе объяснить. Если проще - ты ничего не знаешь о типизации.

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

dart

Дарт и ризон не аналоги TS или Flow. Иначе Си и Haxe можно аналогом назвать. Компилится же в жс

Когда ts-параша начнёт в типы так же, как flow?

Он хотя бы развивается, в отличие от. Может когда-нибудь и начнет. Поживем-увидим. Энивэй, флоу без DefinitelyTyped не нужон. Развитая экосистема > вылизанной системы типов

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

хз о чем ты. Что за базовые типы в реакт-компонентах

Показывай альтернативу

Нетуть. Старый вебпак. Rollup когда-нибудь в будущем

Дело не в плагинах. Компилятор тайпскрипта такая же плагинная система

Не спорю. Я о том, что пакет с тайпскриптом умеет очень много изкоробки. Это как бабель со всеми нужными плагинами и статическим анализатором, линтером и простеньким бандлером. Реальность такова, что выбирать приходится между удобным ts-блобом и модульным нечто, разработчики котрого не знают меру в зависимостях, а пользователи не способны им воспользоваться и предпочитают сборочки (спрашивается, нафиг тогда разбивали на плагины)

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

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

И? Это ничего не меняет. Захочешь что-то сделать - будешь юзать, альтернативы у тебя нет

Как-то выкручиваюсь rollup-ом пока что. Не идеал, конечно

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

А зря не рассказываешь. create-react-app, @vue/cli, @angular/cli etc это стандарт. И это пипец какие огромные нелепые куски непонять чего. Остальные сценарии использования вебпаков с бабелями считай маргинальщина

https://bit.ly/2THlHJ3

Долго не вникал, добавил '[]' в конце декларации args и ошибка пропала. Может и не будет работать как надо, хз

https://bit.ly/2J4zCoB

Непонятно за шиза с методичкой и откуда такое ЧСВ. Ты простой кодер-задрот, как и я. Иначе что ты тут делаешь:) Еще не социализированный, судя по избытку токсичности

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

@export

Как это должно работать? Впервые такое вижу

Ну как-бы тебе объяснить. Если проще - ты ничего не знаешь о типизации.

Хаскелям не обучен, да, но кое-чего смыслю

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

Дарт и ризон не аналоги TS или Flow. Иначе Си и Haxe можно аналогом назвать. Компилится же в жс

Аналог. Просто ты пытаешься подменять понятия, дело в том, что ты выбираешь ТС не потому, что это ТС. У тебя нет выбора. Но ты пытаешься оправдать отсутствие выбора, т.к. ты не хочешь в этом признаться. И ты будешь что угодно придумывать, и как угодно подменять понятия/игнорировать неудебные тезисы, лишь бы крутым было то, что используешь ты.

К тому же, никакого си в жс не компилируется.

Он хотя бы развивается, в отличие от. Может когда-нибудь и начнет. Поживем-увидим. Энивэй, флоу без DefinitelyTyped не нужон. Развитая экосистема > вылизанной системы типов

Ещё раз, никого не волнует твоя попса. Автор тебе заранее определил контекст - он может сам построить себе экосистему, в отличии от тебя.

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

хз о чем ты. Что за базовые типы в реакт-компонентах

О боже. Как реакт-ноду ты можешь передать, собственно, компонент, а можешь любой базовый тип(там строку, число).

Не спорю. Я о том, что пакет с тайпскриптом умеет очень много изкоробки.

Ничего он не умеет.

Это как бабель со всеми нужными плагинами

Неверно.

и статическим анализатором, линтером и простеньким бандлером.

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

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

Да, ты у нас гений. Все такие тупые использует ts-лоадеры. Действительно, почему же. Да потому что тупескрипт-компилятор не может ничего? Представляешь.

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

Я не делаю то, что ненужно мне. К тому же, это днище невозможно исправить - оно порочно изначально.

Как-то выкручиваюсь rollup-ом пока что. Не идеал, конечно

Ещё раз, если ты чем-то выкручиваешься - то у тебя просто очень слабые требования. Зачем ты проецируешь их на остальных?

А зря не рассказываешь. create-react-app, @vue/cli, @angular/cli etc это стандарт. И это пипец какие огромные нелепые куски непонять чего. Остальные сценарии использования вебпаков с бабелями считай маргинальщина

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

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

Твой кругозор крайне низок. Если это всё маргинальщина, то ты не задавал себе такой вопрос. Кто же использует всё то, что не предоставляет дефолтный конфиг create-react-app? Эльфы? Гномы?

Долго не вникал, добавил '[]' в конце декларации args и ошибка пропала. Может и не будет работать как надо, хз

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

К тому же, то что ты видел слово «не массив» и написал [] - это не решает проблемы и никакого отношения к решению не имеет. Ты просто продемонстрировал, что даже о ТС"е ты ничего не знаешь и типизировать ничего сложнее хелворда не сможешь.

Непонятно за шиза с методичкой и откуда такое ЧСВ.

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

Ты простой кодер-задрот, как и я.

Наивный ты человек.

Иначе что ты тут делаешь:)

Не знаю, листал лор в сортире.

Еще не социализированный, судя по избытку токсичности

Ну да, социализация это лизание жоп. Опять проецируешь свои реалии на всех остальных.

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

Как это должно работать? Впервые такое вижу

О боже, я сломал твой парсер. Ну не @export, а @Export. Это не ключевое слово export, а просто какое-то имя.

Хаскелям не обучен

Хаскелисты знают о типах не особо больше тебя.

да, но кое-чего смыслю

Это очень заметно по твоему решению проблемы выше.

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

ты выбираешь ТС не потому, что это ТС. У тебя нет выбора

Ну да. Где тут противоречие? Я бы может и другое что-нибудь выбрал, еслиб оно было и не пришлось самому писать типы для сторонних либ. Все адекватные либы сейчас либо написаны на ТС либо имеют актуальные декларации. Выбор очевиден и он один

Именно поэтому для тебя ТС является божеством

Нее. Божество это Rust. А TS это просто способ не сойти с ума от js в большом проекте

Никто в здравом уме не юзает компилятор тупескрипта

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

К тому же, то что ты видел слово «не массив» и написал [] - это не решает проблемы и никакого отношения к решению не имеет.

Ну так объясни, зачем ты пытаешься задекларировать rest-аргументы функции неитерабельным типом

Ну да, социализация это лизание жоп

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

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

О боже, я сломал твой парсер. Ну не @export, а @Export. Это не ключевое слово export, а просто какое-то имя

Ты как из туалета выйдешь, пример нормально напиши. А то у тебя там декораторы непонять над чем. Какой-то async в середине функции

Это очень заметно по твоему решению проблемы выше

Ты выдал нечто с детской ошибкой про args и комментарием «хелворд, а оно не осилил преобразовать тапл» и хочешь адекватного ответа

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

Ну да. Где тут противоречие? Я бы может и другое что-нибудь выбрал, еслиб оно было и не пришлось самому писать типы для сторонних либ. Все адекватные либы сейчас либо написаны на ТС либо имеют актуальные декларации. Выбор очевиден и он один

В этом и проблемы - ты не можешь оценивать, т.к. ты не имеешь выбора. Поэтому твоя оценка имеет мало смысла, да и её вообще нет. Ты просто хочешь оправдать свой «выбор», не более того.

Нее. Божество это Rust. А TS это просто способ не сойти с ума от js в большом проекте

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

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

Неверно, ты опять всё перепутал. Во-первых, я не говорил про компилять ТС бабелем - я говорил об не использования ts-компилятора, т.е. tsc, о котором ты говорил. Во-вторых, даже бабелем много кто компиляет - можешь посмотреть на какой-нибудь react-hot-loader - достаточно популярный проект.

Ну так объясни, зачем ты пытаешься задекларировать rest-аргументы функции неитерабельным типом

Ты всё перепутал, ещё раз - то что ты там прочитал ошибку не наделяет тебя хоть каким-то понимает. Не нужно пытаться меня забалтывать. Но так уж и быть, я тебе помогу понять проблему: https://bit.ly/2XR57FN

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

Нет никаких оскорблений - там есть твои интерпретации. Ты оскорбляешь меня своими пустыми заявлениями не меньше. Я же не жалуюсь?

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

Ты как из туалета выйдешь, пример нормально напиши. А то у тебя там декораторы непонять над чем. Какой-то async в середине функции

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

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

Ты выдал нечто с детской ошибкой про args и комментарием «хелворд, а оно не осилил преобразовать тапл» и хочешь адекватного ответа

Вот смотри, ты тотальной нулёвый балабол, но ты кидаешься фразами вида «детской», «ошибкой», «ты ничего не сказал» - зачем? И ещё ты мне что-то говоришь об оскорблениях.

Зачем ты играешь со мною в эти игры? Ты не понял, ты не знаешь, но ты строишь из себя кого-то и позволяешь себе обвинять меня.

Ты не знаешь что такое тапл? Что такое преобразование? Ты можешь спросить - это дефолтные базворды, всё это описано в доках.

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

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

https://github.com/microsoft/TypeScript/issues?utf8=✓&q=is:open is:issue ...

723 open.

Например:

https://github.com/Microsoft/TypeScript/issues/30071

interface IFoo<T> {
    test<T2, P extends keyof T2>(obj: T2, property: P): void;
}

class Foo<T> implements IFoo<T> {
    test<T2, P extends keyof T2>(obj: T2, property: P): void {
    }
}
error TS2416: Property 'test' in type 'Foo<T>' is not assignable to the same property in base type 'IFoo<T>'.
  Type '<T2, P extends keyof T2>(obj: T2, property: P) => void' is not assignable to type '<T2, P extends keyof T2>(obj: T2, property: P) => void'. Two different types with this name exist, but they are unrelated.
    Types of parameters 'property' and 'property' are incompatible.
      Type 'P' is not assignable to type 'keyof T2'.
        Type 'keyof T2' is not assignable to type 'keyof T2'. Two different types with this name exist, but they are unrelated.
          Type 'string | number | symbol' is not assignable to type 'keyof T2'.
            Type 'string' is not assignable to type 'keyof T2'.
static_lab ★★★★★
()
Ответ на: комментарий от Noob_Linux

Но он будет значительно хуже по всем параметрам.

Не обязательно он будет хуже того же ангуляра, например. Да, гораздо беднее по функционалу, но не хуже в общем.

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

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

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

Ах да, для общего развития. Ты этой хернёй будешь пхп-дошколят пугать.

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

Ах да, ещё одно. Запомни на будущие, так же для общего развития. Когда я говорю про языки - я не имею ввиду говно для дошколят, самая сложная программа написанная на котором - это очередная лаба.

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

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

Сделал что? Услышал где-то ахинею, повторил, попросили пруфы - кинул первую ссылку из гугла, получил ответ - обосрался? Дак, типичная схема, достойная очередного комнатного гения.

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

Да ну? К чему мне обсираться, когда у меня 2 года F# в продакшене. Бывай.

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

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

Ну т.е. я ничего не увижу? Методичку кинул, обосрался, начал нести ахинею вида «да у меня там», а где «там» показать не хочешь?

Ладно, хорошо, с применением шарпа ты обосрался. Ну дак вернись к теме типизации и вывода типов. Показывай, объясняй - почему в нём есть, а в других языках нет. Или опять кукареку есть, а пруфвов нет?

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

Построить неплохой или сопоставимый по качеству фреймворк могут единицы которые уже освоили основные популярные фреймворки на высоком уровне (знают и потроха, а не просто умеют писать тудушки). И дело не в бедности, а в умении мыслить общими задачами. 9 из 10 «программистов» этого не умеют (из моей личной практики). Даже если ты тот самый и обладаешь нужными скилами трудозатраты на создание фреймворка не сопоставимо больше чем само конечное приложение.

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

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

К тому же, есть ещё один крайне важный нюанс. Фреймворк проектируется под идиота, под тех самых 9/10. И это генерирует ещё половину проблем, которую нужно решить при разработке фреймворка.

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

И что мы имеем? Если нам не нужно толкать фреймворк «в мир», то 95% сложности отпадает само собою(именно такой, рутинной сложности).

Поэтому да, затраты на фреймворк остаются огромными, но они уже сопоставимы с затратами на «приложение». И если у тебя приложение не одно, то ситуация становится ещё лучше.

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

А именно универсальность - основания причина и сложности

нет, не в этом причина.

eсли нам не нужно толкать фреймворк «в мир», то 95% сложности отпадает само собою

с точностью до на оборот, отпадает в лучшем случае процентов 20.

сложно построить не универсальный фреймворк, сложно в принципе сделать то что будет необходимо сделать технически для минимально комфортной работы. Самый простецкий фреймоврк скрывает огромную кучу костылей и хитростией очень не тривиальных т.к. это веб, и их реализация допиливание это больше половины трудозатрат на производство фреймворка. Проще взять какую либо билиотеку рендеринга аля реакт и накрутить вокруг неё свой фреймворк с блекжеком (роутингом) и куртизанками (стейт машиной) и не парить мозг кучей задач которые не относятся на прямую к решению бизнес задачи. Но это всё справедливо только для фронтенда. Для бекенда брать js не стоит если ты не пишешь какой нибудь чатик и тебе нужна асинхронность на бекенде. Реализовать простекое подобие фреймворка на том же PHP в разы проще. Но зачем? Говорю как человек который этим занимался не однократно.

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

нет, не в этом причина.

Ну как же.

Проще взять какую либо билиотеку рендеринга аля реакт

Давай разберём этот пример. Что такое реакт? Это такое нелепое поделие, которое эмулирует поведение пхп для рядового веб-адепта.

Внимание вопрос, с чем обусловлена необходимость подобно решения? Правильно, ЦА. У тебя же её нет. К тому же, сам реакт - это достаточно примитивное изваяние.

Об этом я уже говорил. Если у тебя нет тех, кому нужно эмулировать пхп - тебе не нужен реакт.

свой фреймворк с блекжеком (роутингом) и куртизанками (стейт машиной)

Это всё птушные понятия.

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

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

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

Для бекенда брать js не стоит если ты не пишешь какой нибудь чатик и тебе нужна асинхронность на бекенде.

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

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

Реализовать простекое подобие фреймворка на том же PHP в разы проще. Но зачем? Говорю как человек который этим занимался не однократно.

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

Допустим, я не связан. Меня мало волнуют все эти веб-проблемы. Всякие птушные хттп, роутеры-говноутеры. Всё это протоколы и интерфейсы дерьма. Используя любой птушный фреймворк - я просто пожру дерьма.

А если я не хочу жрать дерьмо, то спокойно беру условный rpc + protobuf + ws и мне как-то похрен на всё. И вебчик не превращается для меня в отдельный мир дерьма, а спокойно интегрируется в сотни лет существующие подходы и инфраструктуру.

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.