romu at soundstep.com (2017-02-09T14:45:57.593Z)
Usually solved this way:
- export something to instantiate (a function or a class)
```
module.exports = MyClass;
```
- export an object (will be shared, only one instance)
```
module.exports = {};
```
- export an object to facilitate the creation of a new instance every time it is called
```
module.exports = {
create: () => {
return new MyClass();
}
};
```romu at soundstep.com (2017-02-09T14:45:05.625Z)
Usually solved this way:
- export something to instantiate (a function or a class)
```
module.exports = MyClass;
```
- export an object (will be shared, only one instance)
```
module.exports = {};
```
- export a new instance every time
```
module.exports = {
create: () => {
return new MyClass();
}
};
```
Usually solved this way: - export something to instantiate (a function or a class) ``` module.exports = MyClass; ``` - export an object (will be shared, only one instance) ``` module.exports = {}; ``` - export a new instance every time ``` module.exports = new MyClass(); ``` On 9 February 2017 at 13:47, Isiah Meadows <isiahmeadows at gmail.com> wrote: > I'm going purely based on memory, but if I recall correctly, the module > name resolution is left entirely to the implementation. That decides > whether two specifiers from two different modules point to the same module. > > (Technically, two modules could even share a file path without being in > violation of the spec. Specifiers are unique, but the spec makes no > normative mention of file paths.) > > On Thu, Feb 9, 2017, 04:37 Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> > wrote: > >> 1) My understanding is that a module is a singleton. But how does the >> spec enforce that? Section 15.2.1.17 HostResolveImportedModule ( >> https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule) says that >> the resolving process of a module must be indempotent. 'Each time it is >> called with a specific referencingModule, specifier pair as arguments it >> must return the same Module Record instance.' >> >> But in the following scenario: >> >> main.js >> ```js >> import a from 'a.js'; >> import b from 'b.js'; >> ``` >> >> a.js >> ```js >> impot c from 'c.js'; >> >> console.log(c); >> ``` >> >> b.js >> ```js >> import c from 'c.js'; >> >> console.log(c); >> ``` >> >> c.js >> ```js >> export default 3; >> ``` >> >> can we be certain that c.js resolves to the same module record and that >> both a.js and b.js print 3? There are two different referencingModule, >> specifier pairs even though the specifier is the same. >> >> 2) Is it correct that it's mandatory for an implementation to produce >> different module instances in every TopLevelModuleEvaluationJobs? So if we >> have two script tags with type module and with the same script content will >> they always produce different module instances or is it possible for an >> implementation to produce modules without executing a >> TopLevelModuleEvaluationJob and reuse module instances? >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- www.soundstep.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170209/034154f5/attachment.html>