Node.js - Recursive Walker

[DreamTheater]

Что делает:
Рекурсивно проходит от указанного корня и эмитирует события о всех найденных файлах и директориях.

Исходный код:

// Walker.js

var EventEmitter = require('events').EventEmitter,

    fs = require('fs'),
    path = require('path'),
    util = require('util');

module.exports = (function () {
    function Walker() {
        EventEmitter.call(this);
    }

    util.inherits(Walker, EventEmitter);

    Walker.prototype.walk = function (from) {
        try {
            var root = path.resolve(from),
                tree = fs.readdirSync(root);

            this.emit('directory', root);

            tree.forEach(function (leaf) {
                var branch = path.join(root, leaf),
                    stats = fs.statSync(branch);

                if (stats.isFile()) {
                    this.emit('file', branch);
                } else {
                    this.walk(branch);
                }
            }, this);
        } catch (error) {
            this.emit('error', error);
        }

        return this;
    };

    return Walker;
}());

Как использовать:

// sandbox.js

var Walker = require('./Walker');

(function () {
    var walker = new Walker();

    walker.on('file', function (file) {
        console.log('file:', file);
    });

    walker.on('directory', function (directory) {
        console.log('directory:', directory);
    });

    walker.on('error', function (error) {
        console.log('error:', error);
    });

    walker.walk('C:\Windows');
}());

Что получится:

directory: C:\Windows
directory: C:\Windows\AppCompat
error: { [Error: EPERM, operation not permitted 'C:\Windows\AppCompat\Programs']
  errno: 50,
  code: 'EPERM',
  path: 'C:\\Windows\\AppCompat\\Programs',
  syscall: 'readdir' }
directory: C:\Windows\AppPatch
file: C:\Windows\AppPatch\AcGenral.dll
file: C:\Windows\AppPatch\AcLayers.dll
...

Работает полностью синхронно, то есть никаких заморочек с коллбэками.

Прошу кидать помидорами.

[Gvozd]

Работает полностью синхронно, то есть никаких заморочек с коллбэками.

Node.js

Не замечаете явной нестыковки?
По-моему должно быть очевидно, что любая библиотека для Node.Js должна быть обязательно ассинхронной(там где нужно и возможно, разумеется), и лишь только во вторую очередь, в ней возможно может быть синхронный вариант для всех ее асинхронных функций.
Или я чего-то не понимаю в Node.js?

[Gvozd]

то есть никаких заморочек с коллбэками.

я увидел в вашем примере "Как использовать:" целых три колбека
Что я делаю не так?

[DreamTheater]

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

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

[Gvozd]

но она же и становится камнем преткновения во многих задачах, когда "коллбэк на коллбэке и коллбэком погоняет"

я где-то слышал фразу о том, что многопоточность во всей ее красе и полноте(с разделением общих ресурсов, и разрешением гонок) хорошо понимают лишь 5% разработчиков.
с асинхронностью похожая ситуация, ИМХО.

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

[DreamTheater]

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

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

[DreamTheater]

Только что написал асинхронный аналог. Время полной отработки внутри каталога C:\Windows ~22 секунды. То же самое но с синхронной реализацией выше - ~1,5 секунды.

Целесообразность использовать асинхронность для меня под сильным вопросом.

[Gvozd]

синхронной реализацией выше - 1,5 секунды.

В эти 1.5 секунды не будет выполнятся никакой другой запрос

~22 секунды.

За эти 22 секунды параллельно могут быть обработаы сотни-тысячи других запросов

[DreamTheater]

В эти 1.5 секунды не будет выполнятся никакой другой запрос

За эти 22 секунды параллельно могут быть обработаы сотни-тысячи других запросов

В случае веб-сервера да, но в случае консольной тулзы это не нужно.

[Gvozd]

В случае веб-сервера да, но в случае консольной тулзы это не нужно.

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