Контекстно зависимый лог
Mar. 24th, 2017 04:06 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthПо-хорошему, надо бы расписать тут длинную историю, почему внутрь модулей CommonJS не стóит пробрасывать лог-функцию, которая точно знает всю цепочку вызовов до модуля.
Но мне лень, поэтому коротко: лучше бы мы не выделывались, достаточно обычного лога.
Хорошо, что рано стало понятно, насколько дорого обходится такой навороченный лог. Так как заранее неизвестно, какой контекст модуль сохраняет между вызовами, нужно этот контекст подменять целиком при каждом вызове.
Вся суть модулей CommonJS – в однократной инициализации и потом быстрых вызовах уже проинициализированного кода. При замене контекста, естеснно, инициализацию в общем случае нужно повторять на каждый новый контекст. Это ничем не отличается от обычного инлайна кода – и полностью противоречит самой сути модулей.
Дополнительно при таком раскладе теряется часть контекста, которую модуль мог захотеть сохранять между вызовами. С одной стороны, никаких утечек памяти, а с другой... Вот любой кэш, например, это как раз управляемая утечка памяти.
В общем, с задачкой на логи я второй раз в жизни сталкиваюсь всерьёз, и во второй раз оказывается, что лог – очень особенный зверёк с инженерной точки зрения.
UPD. Нет худа без добра ) Функционал с контекстно зависимым логом и вообще полным пересозданием контекста мы решили сохранить, просто под другим именем. То-есть у нас будет require() и include().
Обычный require будет работать так же, как нодовский (и CouchDB-шный) CommonJS require. А вот include будет подключать модуль с расширенным контекстом.
Но мне лень, поэтому коротко: лучше бы мы не выделывались, достаточно обычного лога.
Хорошо, что рано стало понятно, насколько дорого обходится такой навороченный лог. Так как заранее неизвестно, какой контекст модуль сохраняет между вызовами, нужно этот контекст подменять целиком при каждом вызове.
Вся суть модулей CommonJS – в однократной инициализации и потом быстрых вызовах уже проинициализированного кода. При замене контекста, естеснно, инициализацию в общем случае нужно повторять на каждый новый контекст. Это ничем не отличается от обычного инлайна кода – и полностью противоречит самой сути модулей.
Дополнительно при таком раскладе теряется часть контекста, которую модуль мог захотеть сохранять между вызовами. С одной стороны, никаких утечек памяти, а с другой... Вот любой кэш, например, это как раз управляемая утечка памяти.
В общем, с задачкой на логи я второй раз в жизни сталкиваюсь всерьёз, и во второй раз оказывается, что лог – очень особенный зверёк с инженерной точки зрения.
UPD. Нет худа без добра ) Функционал с контекстно зависимым логом и вообще полным пересозданием контекста мы решили сохранить, просто под другим именем. То-есть у нас будет require() и include().
Обычный require будет работать так же, как нодовский (и CouchDB-шный) CommonJS require. А вот include будет подключать модуль с расширенным контекстом.