and load it via a memoized getter in the overlay. this means: - it won't have be re-interpreted at each window load (helping multi-window session-restore at startup). - it won't be loaded until the first time PlacesUIUtils is actually used
Taking. Where would the import go? The overlay doesn't have a specific js file that it loads, is it ok if I use utilityOverlay.js for the getter?
Uhm, actually there are too many dependencies on external non-modules and variables to really do this reliably. The following are some examples of what PlacesUIUtils needs that can't be provided when it's turned into a module: utilityOverlay.js functions document window etc. I tried to split it into a utils.js file which would load a PlacesUIUtils.js module, and this would have worked for the as[Query|Container|etc.] functions that were needed by other js files, but not for the functions that PlacesUIUtils itself relies on. Even if I were to strip out all the remaining functions that were dependent on other files and objects, there would have to be a new object to hold them, and the whole tree would have to be updated to s/PlacesUIUtils/PlacesUIUtils2/g wherever those stripped out functions were called. Being that _a_lot_ of the functions rely on external (non-module) js, I don't think there's a big perf win here, but let me know if you're still interested in this scheme, and I'll try to cook something up. unassigning for now.
ok, sounds like a lot of pain for little benefit. thanks for digging into this. -> WONTFIX