module registry observer #450
Conversation
mikea
force-pushed
the
mikea/module-registry-observer
branch
from
f8e2eb0 to
c8ed33a
Compare
mikea
force-pushed
the
mikea/module-registry-observer
branch
from
c8ed33a to
32f236b
Compare
mikea
force-pushed
the
mikea/module-registry-observer
branch
from
32f236b to
4e5f934
Compare
| ModuleInfoCompileOption option, | ||
| const ModuleRegistryObserver& observer) { | ||
| // destroy the observer after compilation finished to indicate the end of the process. | ||
| auto compilationObserver = observer.onEsmCompilationStart(js.v8Isolate, name, option); |
There was a problem hiding this comment.
If I understand what could be happening here: an observer returns an owned which is an opaque container (kj::Own<void>) for a class / struct that "observes" the start and end of compilation events when the opaque container is created and destroyed. A ModuleRegisryObserver implementation can choose what happens on start and end of compilation. The LHS is doing the observing the end of the compilation on behalf of the ModuleRegistryObserver, e.g. compilationEndObserver.
I might call compilationObserver something like compilationEvent / compilationLifetime
There was a problem hiding this comment.
Thanks. I thought about it a little bit, and decided to keep the name observer.
Couple reasons:
- we already use destructor in observers to send an event, so this usage/naming is consistent
- this observer is very simple now (only destructor), but may get additional methods in the future or got rid of the destructor altogether if we need to send more information (e.g. successful/non-successful)
Let me know if you feel strongly about this one.
enables recording timing/memory/usage information
EW PR 5129