Comments 7
Что мне не нравится в модуле
fs, так что это, что синхронные и асинхронные операции свалены в одном нейсмспейсе. А чтобы избежать коллизий, синхронные функции получили уродливый постфикс Sync. Я бы просто выделил в модуле суб-пространство имён sync и в нём все функции имели бы такие же имена, как и асинхронные. Также в дальнейшем так можно было бы добавить суб-пространство имён promise и положить туда аналогичный набор функций, возвращающий промисы. Многие библиотекостроители догадались до этого манёвра, в результате мы имеем опрятное API в библиотеках glob, cp, mkdirp, touch и других.
Есть библиотека bluebird, с промисами быстрее, чем в v8. Так вот там есть метод promisifyAll, позволяющий все функции с колбеками превратить в функции, возвращающие промисы и по умолчанию ко всем функциям просто добавляется Async.
Так что это просто особенности API, возможно не слишком удачного, но устоявшегося.
Так что это просто особенности API, возможно не слишком удачного, но устоявшегося.
особенности API, … не слишком удачного, но устоявшегосяОб этом я и веду речь.
1. Если сделать
dir(fs), то получим солянку из двух API, в которых зрительно придётся выделять sync/async функции.2. В любой подсистеме, как правило, используется одно из двух API. Для скриптов синхронное, для серверов асинхронное. Нет необходимости валить их в один модуль. Они могли бы быть в разных пространствах имён или даже в разных модулях.
3. Префиксы-постфиксы это очень грязная практика, так как в определённый момент возникает ситуация, когда для получения нужной функциональности приходится конструировать её имя. В итоге, приходится доблестно решать проблему доступа к объекту, которую мы сами создали какое-то время назад. Всегда, когда есть возможность, лучше пользоваться языковыми средствами, например пространствами имён.
Теперь Вы можете предварительно загрузить модули во время выполнения скриптов или использования REPL. Сделать это можно с помощью -r или флага --require.Очень здравая фишка, но это не всё, что можно с этим сделать. Ещё более интересный кейс: загрузить модули и/или скрипты, выполнить их и перейти в REPL с результатами работы в
global. Когда-то приходил в трекер ноды с таким запросом, но был непонят. В ноде есть флаг --interactive но он имеет контр-интуитивный смысл.Необходимость не пропадала и я запилил для этих задач модуль repl.js и сейчас его широко использую в различных экспериментах с кодом, проверке идей и т.п.
А разве io.js до сих пор существует? В смысле активной разработки?
да. Пока происходит воссоединение, мир не стоит на месте. На пример недавно был релиз 2.3.0.
github.com/nodejs/io.js
Они до 3.0 будут поддерживать его. А после мержа будут работать уже над одним продуктом.
Они до 3.0 будут поддерживать его. А после мержа будут работать уже над одним продуктом.
Sign up to leave a comment.
Новые возможности io.js, которые Вы возможно не используете