Move memoizeIntlObject to Scope

[stasm]

Now that Scope is a proper class, we can move some private logic from FluentBundle to it.

I'm keeping Scope.bundle which still exposes _messages, _terms etc. We could move assign them explicitly inside Scope, too, but they still need to be fields on FluentBundle anyways, since we need them for storage. I'd rather just wait for private fields than work around their lack with WeakMap or some other fashion.

[Pike]

This moves caching of number formatters from being per bundle to being per formatPattern call, right? Is that actually caching them in practice then? I would assume that the cases where we need them are rare, and where we need them multiple times in one pattern even more so?

[stasm]

No, they're still stored in bundle._intls. This just moves the code that does the caching.

[eemeli]

Would it make sense to make _intls a local variable in scope.js rather than a bundle member, so that it'd get cached across all uses? Also, with Intl objets as keys, does the WeakMap ever get garbage-collected?

[stasm]

Would it make sense to make _intls a local variable in scope.js rather than a bundle member, so that it'd get cached across all uses?

Hmm, I think we'd then need to key on the locale of the bundle in addition to already keying on the constructor and the serialized options. Definitely possible. Is the expected benefit that multiple bundles in the same locale would use a single cached instance any particular intl formatter?

Also, with Intl objets as keys, does the WeakMap ever get garbage-collected?

In the current code, when the WeakMap is a field on FluentBundle, I expect it to be GC-ed together with the instance of the bundle.

[Pike]

Technically, this is correct.

I continue dislike the design decision, but that's a different question.

As for more aggressive caching, we'd need to cache on locale list of the bundle, not locale. Also, for server-side uses with many languages, this might turn into long time memory usage that's hard to control.

[stasm]

Thanks, @Pike, for your help and the review. I'm open to continuing the discussion about the internal design of FluentBundle as well as about caching.