Войти
ПрограммированиеФорумВеб

Javascript/Node.js this

#0
20:59, 24 дек. 2012

вот пример кода с использованием node.js и express

http.createServer(app).listen(app.get('port'), function () {
  console.log("Server listening on port %d in %s mode", /**/this/**/.address().port, app.settings.env);
});
с помощью
/**/
выделено интересующее место
и собственно вопрос, подобное поведение для callback функций,
т.е. установка контекста вызова, стандартизировано в node.js
и этим можно пользоваться, или правильнее все же использовать замыкания
вида
var server = http.createServer(app);
server.listen(app.get('port'), function () {
  console.log("Server listening on port %d in %s mode", /**/server/**/.address().port, app.settings.env);
});

#1
21:14, 24 дек. 2012

Мне кажется очевидно надо использовать замыкания ;)
Но node.js это порождение зла и должно отправиться обратно в ад, откуда оно пришло. Ненадёжная виртуальная машина, падающий постоянно сервис демонизации, нестабильное потребление памяти, богопротивный яваскрипт с неочевидными приведениями типов, и просто лапша из колбеков.

#2
21:21, 24 дек. 2012

kvakvs
> Мне кажется очевидно надо использовать замыкания ;)
оно не так очевидно, когда понимаешь, что конкретно в том примере происходит засорение пространства имен,
и тем более замыкание в данном случае является избыточным механизмом, ведь callback функция вызывается уже в контексте нужного объекта,
а с замыканиями мы рискуем обратиться вообще не к связанной с проблемой переменной, вместо той о которой мы думали.

kvakvs
> падающий постоянно сервис демонизации
сервис демонизации?
вроде же нету сервиса демонизации стандартного, по крайней мере.

#3
22:04, 24 дек. 2012

cNoNim
> и тем более замыкание в данном случае является избыточным механизмом, ведь
> callback функция вызывается уже в контексте нужного объекта
Если у тебя имеется неявная переменная this (я обожаю неявности в разработке), то пользуйся ею, но всё равно рано или поздно тебе понадобится почерпнуть какое-то значение из окружающего колбек кода. Вот именно здесь и полезно замыкание. Можно им с самого начала пользоваться и не париться.

#4
6:46, 25 дек. 2012

cNoNim
> и собственно вопрос, подобное поведение для callback функций,
> т.е. установка контекста вызова, стандартизировано в node.js
> и этим можно пользоваться, или правильнее все же использовать замыкания
> вида

Замыкания. С пару месяцев назад только было что чувачок в node.js как раз забыл про то что this - это штука бесхребетная в JS и от любого чиха превращается во что угодно, только не в настоящий this, поэтому кложурами только если обернуть появляются гарантии хоть какие то.

#5
9:20, 25 дек. 2012

Именно поэтому становится очевидной необходимость использования Dirt'a  и ему подобных:)

#6
13:21, 25 дек. 2012
пишите на джаве, зачем поедать эти кактусы с нодой и богомерзким js?
#7
17:56, 25 дек. 2012

Mephistopheles
А клиентскую часть тоже на джаве? Node.JS очень удобная штука, когда пишешь веб приложение. Особенно в связке c Socket.IO. В вашей чашечке что-то подобное есть?

#8
18:41, 25 дек. 2012

AgentX001
А ты клиентскую часть на ноде пишеш О_О

AgentX001
> В вашей чашечке что-то подобное есть?
Много чего есть, в том числе и либы для работы с вебсокетами:)

AgentX001
> А клиентскую часть тоже на джаве?
В принципе на javaFX можно и фронт запилить, но там свои особености

#9
22:17, 25 дек. 2012

Mephistopheles
> А ты клиентскую часть на ноде пишеш О_О
Вообще это возможно, но я не о том:) Я про то, что можно писать и сервер и клиент на одном ЯП. А это знаешь, ли, доставляет:)
Mephistopheles
> Много чего есть, в том числе и либы для работы с вебсокетами:)
Socket.IO - это не совсем либа для работы с вебсокетами:

In order to provide realtime connectivity on every browser, Socket.IO selects the most capable transport at runtime, without it affecting the API.

WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling


А у вас?;)
#10
1:11, 26 дек. 2012

Лучше указывать объект по имени. В первую очередь - так понятнее.

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

#11
1:25, 26 дек. 2012

Fynivx
> Кроме того, лучше обзавестись привычкой не использовать анонимные функции для
> кэллбэков.
А если нужно сделать что-то вроде того, что у ТС? Ради строчки кода объявлять функцию?

#12
1:33, 26 дек. 2012

AgentX001
> А это знаешь, ли, доставляет:)
Тут не могу не согласиться, это действительно клево. Но не более.

AgentX001
> А у вас?;)
закончу твои страдания: есть порт Socket.io для джавы :)

Да и вообще с джавой тягяться в области веб технологий сможет разве что asp.net, нода даже рядом не стояла.

#13
4:47, 26 дек. 2012

Зависит от библиотеки которая вызывает callback. Кто-то его просто вызывает, а кто-то использует apply при вызове, что гарантирует передачу области переменных в callback функцию.

Например:

function Worker(task) {
  this.task = task
}
Worker.prototype.process = function(callback) {
  // do some work {
    // after work is done, time for callback
    if (callback) {
      callback.apply(this, [ false ]);
    }
  // }
}

// test case
var worker = new Worker('test');

worker.process(function(err) {
  if (!err) {
    console.log(this.task);
  }
});

Я предпочитаю использовать this, если знаю что callback не будет привязывать область переменных в какой-то профанской библиотеке (хотя логичней привязывать, т.к. этого все и ожиают), то можно ещё использовать .bind - что привязывает область переменных к самой функции до её вызова:

function Worker(task) {
  this.task = task
}
Worker.prototype.process = function(callback) {
  // do some work {
    // after work is done, time for callback
    if (callback) {
      callback(false);
    }
  // }
}

// test case
var worker = new Worker('test');

worker.process((function(err) {
  if (!err) {
    console.log(this.task);
  }
}).bind(worker));

Если ты разрабатываешь библиотеку, используй первый вариант - он чище, и код в итоге не страдает от .bind'ов.

ЗЫ.
У многих конкретный зуд кое-где из-за node.js потому что он тупо рвёт ранее привычные абстракции во многих популярных ЯП и платформах.
И т.к. не каждый способен пнять фишку, и осознать потенциал, сразу же начинают грызть в ответ.

Лично я его использую по работе, реализовали большой API с огромной БД (mongo), и я не мог представить и лучше варианта, с какой масштабируемостью, стабильностью, а главное кайфом это дело было кодить и нынче поддерживать.

#14
4:41, 21 янв. 2013

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

Калбеки конечно жопа, но с файберами их можно обойти.

ПрограммированиеФорумВеб

Тема в архиве.