и если на сервере 64 ядра, то можно и юзать его

Не советуй людям плохого =__=

Я вот так в лог пишу: https://github.com/ChALkeR/whiner/blob/master/index.js

а чем тебе пино от твоего коллеги по ctc не угодил? :)

а чем тебе пино от твоего коллеги по ctc не угодил? :)

А из JS будешь иметь доступ к глобальной переменной

а обогнал bole потому что он в фастифай в депсы пино сунул)

https://github.com/devslaw/TypeScript-Node.js-REST-example

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

сишарперы и жависты

Круто. Жаль, не видел такого никогда раньше (сам на шарпе пишу)

а здесь что забыл?

И это ад. У меня сейчас такое же по наследству. Только логика раз в N сложнее, поэтому ад вдвойне.

Если не городить наследование, то всё норм должно быть

Если не городить наследование, то всё норм должно быть

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

классы для методов инстанса а не для наследования-only

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

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

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

на модулях ты сможешь сделать методы инстанса?

Как я понял, он говорит, что эти два варианта идентичны: //1 class foo { constructor(a) { this.a = a; } foo() { ++this.a } } //2 let a = 0; function foo() { ++a; }

Классы очень хорошо существуют без наследования. Удобно хранить состояния

Так я не против классов. Я лишь прошу не устраивать ООПизацию всего и вся. Если это где-то задел на будущее и ради общего стайла в проекта - подумать и отказаться. Будущее наступит, но половина классов так и не вырастет.

Как я понял, он говорит, что эти два варианта идентичны: //1 class foo { constructor(a) { this.a = a; } foo() { ++this.a } } //2 let a = 0; function foo() { ++a; }

Не совсем так. Но в этом конкретном примере представь, что такой класс у тебя будет использоваться ровно один раз в проекте (я даже не про синглтон). Или один раз на один запрос. Зачем здесь класс?

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

Сейчас почитываю о Go, решили они проблему с классами, конечно. С пробелами и табуляцией. Здорово на самом деле

Проблему? А что там было?

Их там просто нет. Нет там проблем

Сейчас почитываю о Go, решили они проблему с классами, конечно. С пробелами и табуляцией. Здорово на самом деле

А какие проблемы с классами

А какие проблемы с классами

А где есть?

Викторина глупых вопросов. Как передать элемент массива в конфигурационном файле другом элементу? например: db:{ user:"login", password:"pass" }, sequelize:{ database: db.database, username: db.username, password: db.password, }

Не совсем понятен вопрос. Что в итоге нужно получить?

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

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

Здравствуйте, возможно ли закрыть выполнение всех промисов в приложении ? Например, закрытие сокета-> закрытие всех promise

А какие проблемы с классами

Не дожидаться reject или resolve

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

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