Comments 22
Всё не осилил, но если я правильно понял — это какая-то порочная идея.
Может быть, стоит просто понять саму идею и писать так как оно получается в «натуральном» виде, чем пытаться как-то привести всё костылями к привычному?
Когда начал осваивать Node.js долго плевался на кажущееся неудобство. А когда понял и принял саму идею — всё стало клёво.
А тут КОП прямо-таки получается (костыльно-ориентированное программирование) :)
Это всё имхо.
Может быть, стоит просто понять саму идею и писать так как оно получается в «натуральном» виде, чем пытаться как-то привести всё костылями к привычному?
Когда начал осваивать Node.js долго плевался на кажущееся неудобство. А когда понял и принял саму идею — всё стало клёво.
А тут КОП прямо-таки получается (костыльно-ориентированное программирование) :)
Это всё имхо.
Вы в nodejs еще столкнетесь с ситуацией, когда у вас будет 20 вложенных коллбеков, такой код читать и править — ад, это только одна из проблем асинхронного JS. Тогда вы вспомните про эту статью.
Ну так именованные функции решают. А часть из этих колбеков должна быть реализована в самом фреймворке, пусть и частично по типу приведённых выше библиотек. тогда и использование будет прозрачнее, и «лестничного» кода не будет.
А библиотеки эти, имхо, больше нужны не для создания цепочки коллбеков, а более сложных вещи, например «параллельного» выполнения нескольких функций передачей результатов всех по завершении дальше по цепочке. Если бы они ещё научились работать с web-workers для действительно параллельного, а не асинхронного выполнения — цены бы им не было.
А библиотеки эти, имхо, больше нужны не для создания цепочки коллбеков, а более сложных вещи, например «параллельного» выполнения нескольких функций передачей результатов всех по завершении дальше по цепочке. Если бы они ещё научились работать с web-workers для действительно параллельного, а не асинхронного выполнения — цены бы им не было.
Кажется, что с именованными коллбеками будет одна проблема — порядок выполнения как-бы разворачивается наоборот. Часто эти коллбеки отвечают просто за последовательные шаги какого-то алгоритма. Но сначала пишем обработчик коллбека, потом код, который его вызовет. Поэтому, чтобы понять логику выполнения, нужно постоянно код то снизу вверх читать (прыгая к обработчику), то сверху вниз (читая код обработчика) — в отличие от обычного синхронного кода.
У меня большого опыта тут нет, не подскажете — это решается чем-то вроде Module Pattern? Или нет такой проблемы совсем?
У меня большого опыта тут нет, не подскажете — это решается чем-то вроде Module Pattern? Или нет такой проблемы совсем?
функции можно определять и после использования
function getData(){
}
getData( processData )
function processData( data ){
storeData( storeData )
}
function storeData( data ){
}
function getData(){
}
getData( processData )
function processData( data ){
storeData( storeData )
}
function storeData( data ){
}
Согласен, важно понимать различие
от
но kmike наверное, имел ввиду то, что для него проблематично скроллить код от места вызова обработчика до описания обработчика и обратно, а вверх скроллить или вниз, в поисках кода обработчика, какая разница?
var handler = function(){...}от
function handler(){...}но kmike наверное, имел ввиду то, что для него проблематично скроллить код от места вызова обработчика до описания обработчика и обратно, а вверх скроллить или вниз, в поисках кода обработчика, какая разница?
О, точно. Проблема значит выдуманная.
Посмотрите, к примеру, Step:
Step(
// Loads two files in parallel
function loadStuff() {
fs.readFile(__filename, this.parallel());
fs.readFile("/etc/passwd", this.parallel());
},
// Show the result when done
function showStuff(err, code, users) {
if (err) throw err;
sys.puts(code);
sys.puts(users);
}
)
* This source code was highlighted with Source Code Highlighter.и вообще, почему у меня интервью не взяли?!? >_<
FAsyncPipe
( FCollector
( { code: function(){ fs.readFile( __filename, this ) }
, users: function(){ fs.readFile( "/etc/passwd", this ) }
}
)
, function showStuff( res ){
sys.puts(res.code);
sys.puts(res.users);
}
}
)
jsfiddle.net/FZqZN/3716/
FAsyncPipe
( FCollector
( { code: function(){ fs.readFile( __filename, this ) }
, users: function(){ fs.readFile( "/etc/passwd", this ) }
}
)
, function showStuff( res ){
sys.puts(res.code);
sys.puts(res.users);
}
}
)
jsfiddle.net/FZqZN/3716/
Вы правы по поводу целей этих библиотек — они реализуют асинхронные шаблоны. Если использовать их, то проблема «лестничного» кода решается автоматически (лестницы критически уменьшаются до удобоваримых 2х-3х этажей) без именования коллбеков. И избавление от такого кода — первое, что может оценить человек, который пока не оценил или не разобрался с этими бибиотеками.
Это частично решаеться вынесением каждого калбека (или не каждого а только основной логики) в свое событие, и тогда когд сводиться только к генерации евентов
звучит как угроза =)
+1, мне тоже так кажется. «Каша» коллбеков обычно означает что одна функция пытается сделать слишком многое. Такое надо разбивать на подзадачи и каждую оборачивать в отдельную асинхронную функцию.
чувствую, что наличие столь большого числа библиотек, как Flow-js, является только свидетельством того, что Javascript на самом деле неудачен для параллельного программирования.
yess.jpg!!! В том смысле, что JS не настолько «идеален» для асинхронного программирования, как многие уверяют.
А вот эта ссылка — JavaScript Iterators and generators понравилась.
и какой вывод? что лучше использовать?
За перевод спасибо!
Isaac — что не ответ, то шедевр, а главное по делу.
Жаль что JSDeferred не попала в список.
Isaac — что не ответ, то шедевр, а главное по делу.
Жаль что JSDeferred не попала в список.
вместо перекладывания ответственности на прикладной код, умники, разрабатывающие браузеры, давно должны были сделать выполнение яваскрипта в нескольких потоках. например, чтобы разные блоки «скрипт тайп=яваскрипт» выполнялись в отдельных потоках, ну или как-то еще по-хитрому
раздули проблему из ничего, из-за того, что кто-то не хочет правильно делать программы
я щетаю так
раздули проблему из ничего, из-за того, что кто-то не хочет правильно делать программы
я щетаю так
Тогда сразу появляется проблема гонок и fine-grained locking.
У многопоточности свои проблемы. Считается что асинхронная обработка запросов как в nodejs позволяет достигать большей производительности чем многопоточная реализация по виду апача. Поэтому асинхронные библиотеки тоже нужны, но видимо пока нет стандарта де факто.
Sign up to leave a comment.
Асинхронное программирование на JavaScript — Остаться в живых