Detecting a Module object
Can't. 'toString' might be a binding exported by a module so a module object can have its own toString method (or any other non export properties).
However, I've been think that it may be reasonable for Object.prototype.toString to have special case handling of Module objects. eg:
Object.prototype.toString.call(someModule) // "[object Module]"
But, what's you use case? Other than for debugging output, when would you need to check in an arbitrary object is a Module object?
On Feb 20, 2014, at 11:47 AM, Guy Bedford wrote: > If Module objects are not classes, then what would be the recommended way to detect if a given object is a Module? > > Would there be a unique toString output? Can't. 'toString' might be a binding exported by a module so a module object can have its own toString method (or any other non export properties). However, I've been think that it may be reasonable for Object.prototype.toString to have special case handling of Module objects. eg: Object.prototype.toString.call(someModule) // "[object Module]" But, what's you use case? Other than for debugging output, when would you need to check in an arbitrary object is a Module object? Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140220/ce84aaba/attachment.html>
Thanks, if there is some way to detect this it may well be useful.
The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work.
Thanks, if there is some way to detect this it may well be useful. The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. On 20 February 2014 22:31, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > > On Feb 20, 2014, at 11:47 AM, Guy Bedford wrote: > > If Module objects are not classes, then what would be the recommended way > to detect if a given object is a Module? > > Would there be a unique toString output? > > > Can't. 'toString' might be a binding exported by a module so a module > object can have its own toString method (or any other non export > properties). > > However, I've been think that it may be reasonable for > Object.prototype.toString to have special case handling of Module objects. > eg: > Object.prototype.toString.call(someModule) // "[object Module]" > > But, what's you use case? Other than for debugging output, when would you > need to check in an arbitrary object is a Module object? > > Allen > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140220/5c2fda11/attachment.html>
The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them...
On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: > Thanks, if there is some way to detect this it may well be useful. > > The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... Allen
Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like:
define(['a', 'b'], function(a, b) {
if (!(a instanceof Module)) a = { default: a }
if (!(b instanceof Module)) b = { default: b }
....
so his generated AMD code can accept ES6 modules.
On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > > On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: > > > Thanks, if there is some way to detect this it may well be useful. > > > > The use case I came across it was trying to allow ES6 modules to be > transpiled into AMD for use in an ES6 loader. I'm still not sure how > necessary the use case is, but it definitely would need this functionality > work. > > The Es6 module loader design has specific hooks to support importing from > foreign module systems. However, I'll leave it to Dave or Sam to explain > how to use them... > Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: define(['a', 'b'], function(a, b) { if (!(a instanceof Module)) a = { default: a } if (!(b instanceof Module)) b = { default: b } .... so his generated AMD code can accept ES6 modules. HTH, jjb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140220/f896fefd/attachment-0001.html>
Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined.
Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD.
It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - gist.github.com/guybedford/5622c9ed5c9ad4bc0417.
The key point being raised here is that there is a scenario in which detecting a module instance is useful.
Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. The key point being raised here is that there is a scenario in which detecting a module instance is useful. On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: > > > > On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > >> >> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >> >> > Thanks, if there is some way to detect this it may well be useful. >> > >> > The use case I came across it was trying to allow ES6 modules to be >> transpiled into AMD for use in an ES6 loader. I'm still not sure how >> necessary the use case is, but it definitely would need this functionality >> work. >> >> The Es6 module loader design has specific hooks to support importing from >> foreign module systems. However, I'll leave it to Dave or Sam to explain >> how to use them... >> > > Guy is trying to support an important path for JS developers to get to ES6 > and adopt ES module loading: allow developers to mix ES6 and AMD modules. > He already supports loading AMD via ES6-loader. Now he wants to allow > that AMD code to depend upon ES6 modules. This allows AMD teams to > transition smoothly to ES6. He needs something like: > define(['a', 'b'], function(a, b) { > if (!(a instanceof Module)) a = { default: a } > if (!(b instanceof Module)) b = { default: b } > .... > so his generated AMD code can accept ES6 modules. > > HTH, > jjb > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140221/56b2e4a8/attachment.html>
Being able to do m instanceof Module
is certainly a lot nicer here though.
Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods.
Being able to do `m instanceof Module` is certainly a lot nicer here though. Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: > Thanks John for explaining. As for the usefulness of this path as I say it > is yet to be determined. > > Specifically the ability to detect a module instance is needed to allow > ES6 loaders to load AMD that was transpiled from ES6 into AMD. > > It may be a little bit of an obscure use case, the exact details of the > use case are described in this gist - > https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. > > The key point being raised here is that there is a scenario in which > detecting a module instance is useful. > > > On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: > >> >> >> >> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com >> > wrote: >> >>> >>> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >>> >>> > Thanks, if there is some way to detect this it may well be useful. >>> > >>> > The use case I came across it was trying to allow ES6 modules to be >>> transpiled into AMD for use in an ES6 loader. I'm still not sure how >>> necessary the use case is, but it definitely would need this functionality >>> work. >>> >>> The Es6 module loader design has specific hooks to support importing >>> from foreign module systems. However, I'll leave it to Dave or Sam to >>> explain how to use them... >>> >> >> Guy is trying to support an important path for JS developers to get to >> ES6 and adopt ES module loading: allow developers to mix ES6 and AMD >> modules. He already supports loading AMD via ES6-loader. Now he wants to >> allow that AMD code to depend upon ES6 modules. This allows AMD teams to >> transition smoothly to ES6. He needs something like: >> define(['a', 'b'], function(a, b) { >> if (!(a instanceof Module)) a = { default: a } >> if (!(b instanceof Module)) b = { default: b } >> .... >> so his generated AMD code can accept ES6 modules. >> >> HTH, >> jjb >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140221/5f9d3f36/attachment.html>
it's not going to be instanceof for various technical reasons.
I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule...
it's not going to be instanceof for various technical reasons. I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule... Allen On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: > Being able to do `m instanceof Module` is certainly a lot nicer here though. > > Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. > > > On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: > Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. > > Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. > > It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. > > The key point being raised here is that there is a scenario in which detecting a module instance is useful. > > > On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: > > > > On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > > On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: > > > Thanks, if there is some way to detect this it may well be useful. > > > > The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. > > The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... > > Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: > define(['a', 'b'], function(a, b) { > if (!(a instanceof Module)) a = { default: a } > if (!(b instanceof Module)) b = { default: b } > .... > so his generated AMD code can accept ES6 modules. > > HTH, > jjb > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140221/60b8c14e/attachment-0001.html>
I think it should be Module.isModule.
I think it should be Module.isModule. Dave On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > it's not going to be instanceof for various technical reasons. > > I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule... > > Allen > > > On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: > >> Being able to do `m instanceof Module` is certainly a lot nicer here though. >> >> Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. >> >> >> On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: >> Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. >> >> Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. >> >> It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. >> >> The key point being raised here is that there is a scenario in which detecting a module instance is useful. >> >> >> On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: >> >> >> >> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >> >> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >> >> > Thanks, if there is some way to detect this it may well be useful. >> > >> > The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. >> >> The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... >> >> Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: >> define(['a', 'b'], function(a, b) { >> if (!(a instanceof Module)) a = { default: a } >> if (!(b instanceof Module)) b = { default: b } >> .... >> so his generated AMD code can accept ES6 modules. >> >> HTH, >> jjb >> >> > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
Is Module a global now?
Is Module a global now? ________________________________________ From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of David Herman <dherman at mozilla.com> Sent: Friday, February 21, 2014 15:08 To: Allen Wirfs-Brock Cc: es-discuss Subject: Re: Detecting a Module object I think it should be Module.isModule. Dave On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > it's not going to be instanceof for various technical reasons. > > I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule... > > Allen > > > On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: > >> Being able to do `m instanceof Module` is certainly a lot nicer here though. >> >> Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. >> >> >> On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: >> Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. >> >> Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. >> >> It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. >> >> The key point being raised here is that there is a scenario in which detecting a module instance is useful. >> >> >> On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: >> >> >> >> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >> >> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >> >> > Thanks, if there is some way to detect this it may well be useful. >> > >> > The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. >> >> The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... >> >> Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: >> define(['a', 'b'], function(a, b) { >> if (!(a instanceof Module)) a = { default: a } >> if (!(b instanceof Module)) b = { default: b } >> .... >> so his generated AMD code can accept ES6 modules. >> >> HTH, >> jjb >> >> > > _______________________________________________ > 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
no, it's in Reflect
no, it's in Reflect Dave On Feb 21, 2014, at 12:13 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote: > Is Module a global now? > ________________________________________ > From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of David Herman <dherman at mozilla.com> > Sent: Friday, February 21, 2014 15:08 > To: Allen Wirfs-Brock > Cc: es-discuss > Subject: Re: Detecting a Module object > > I think it should be Module.isModule. > > Dave > > On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > >> it's not going to be instanceof for various technical reasons. >> >> I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule... >> >> Allen >> >> >> On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: >> >>> Being able to do `m instanceof Module` is certainly a lot nicer here though. >>> >>> Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. >>> >>> >>> On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: >>> Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. >>> >>> Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. >>> >>> It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. >>> >>> The key point being raised here is that there is a scenario in which detecting a module instance is useful. >>> >>> >>> On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: >>> >>> >>> >>> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >>> >>> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >>> >>>> Thanks, if there is some way to detect this it may well be useful. >>>> >>>> The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. >>> >>> The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... >>> >>> Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: >>> define(['a', 'b'], function(a, b) { >>> if (!(a instanceof Module)) a = { default: a } >>> if (!(b instanceof Module)) b = { default: b } >>> .... >>> so his generated AMD code can accept ES6 modules. >>> >>> HTH, >>> jjb >>> >>> >> >> _______________________________________________ >> 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
On Feb 21, 2014, at 12:08 PM, David Herman wrote:
I think it should be Module.isModule.
I don't think we actually need something named Module, but that's a separate conversation I have in the queue to have with you.
But food for thought: for module loader reflection purposes, it would be better for use a mirror-like object rather than the actual magic module objects.
On Feb 21, 2014, at 12:08 PM, David Herman wrote: > I think it should be Module.isModule. I don't think we actually need something named Module, but that's a separate conversation I have in the queue to have with you. But food for thought: for module loader reflection purposes, it would be better for use a mirror-like object rather than the actual magic module objects. allen > > Dave > > On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > >> it's not going to be instanceof for various technical reasons. >> >> I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule... >> >> Allen >> >> >> On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: >> >>> Being able to do `m instanceof Module` is certainly a lot nicer here though. >>> >>> Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. >>> >>> >>> On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: >>> Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. >>> >>> Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. >>> >>> It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. >>> >>> The key point being raised here is that there is a scenario in which detecting a module instance is useful. >>> >>> >>> On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: >>> >>> >>> >>> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >>> >>> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >>> >>>> Thanks, if there is some way to detect this it may well be useful. >>>> >>>> The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. >>> >>> The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... >>> >>> Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: >>> define(['a', 'b'], function(a, b) { >>> if (!(a instanceof Module)) a = { default: a } >>> if (!(b instanceof Module)) b = { default: b } >>> .... >>> so his generated AMD code can accept ES6 modules. >>> >>> HTH, >>> jjb >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > >
OK, we can discuss and report back. We'll definitely want to take into account Guy's use case about being able to recognize module instance objects as such.
OK, we can discuss and report back. We'll definitely want to take into account Guy's use case about being able to recognize module instance objects as such. Dave On Feb 21, 2014, at 12:53 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > > On Feb 21, 2014, at 12:08 PM, David Herman wrote: > >> I think it should be Module.isModule. > > I don't think we actually need something named Module, but that's a separate conversation I have in the queue to have with you. > > But food for thought: for module loader reflection purposes, it would be better for use a mirror-like object rather than the actual magic module objects. > > allen > > > > > >> >> Dave >> >> On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >> >>> it's not going to be instanceof for various technical reasons. >>> >>> I suspect, we can have a isModule predicate function somewhere. Perhaps, Reflect.isModule or Reflect.Loader.isModule... >>> >>> Allen >>> >>> >>> On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: >>> >>>> Being able to do `m instanceof Module` is certainly a lot nicer here though. >>>> >>>> Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. >>>> >>>> >>>> On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: >>>> Thanks John for explaining. As for the usefulness of this path as I say it is yet to be determined. >>>> >>>> Specifically the ability to detect a module instance is needed to allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. >>>> >>>> It may be a little bit of an obscure use case, the exact details of the use case are described in this gist - https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. >>>> >>>> The key point being raised here is that there is a scenario in which detecting a module instance is useful. >>>> >>>> >>>> On 20 February 2014 23:45, John Barton <johnjbarton at google.com> wrote: >>>> >>>> >>>> >>>> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >>>> >>>> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: >>>> >>>>> Thanks, if there is some way to detect this it may well be useful. >>>>> >>>>> The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use in an ES6 loader. I'm still not sure how necessary the use case is, but it definitely would need this functionality work. >>>> >>>> The Es6 module loader design has specific hooks to support importing from foreign module systems. However, I'll leave it to Dave or Sam to explain how to use them... >>>> >>>> Guy is trying to support an important path for JS developers to get to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD modules. He already supports loading AMD via ES6-loader. Now he wants to allow that AMD code to depend upon ES6 modules. This allows AMD teams to transition smoothly to ES6. He needs something like: >>>> define(['a', 'b'], function(a, b) { >>>> if (!(a instanceof Module)) a = { default: a } >>>> if (!(b instanceof Module)) b = { default: b } >>>> .... >>>> so his generated AMD code can accept ES6 modules. >>>> >>>> HTH, >>>> jjb >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >
Has there been any further discussion on this? It would be good to know the form so that ES6 modules currently being generated today will not break in real ES6 environments.
Has there been any further discussion on this? It would be good to know the form so that ES6 modules currently being generated today will not break in real ES6 environments. On 21 February 2014 13:30, David Herman <dherman at mozilla.com> wrote: > OK, we can discuss and report back. We'll definitely want to take into > account Guy's use case about being able to recognize module instance > objects as such. > > Dave > > On Feb 21, 2014, at 12:53 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> > wrote: > > > > > On Feb 21, 2014, at 12:08 PM, David Herman wrote: > > > >> I think it should be Module.isModule. > > > > I don't think we actually need something named Module, but that's a > separate conversation I have in the queue to have with you. > > > > But food for thought: for module loader reflection purposes, it would be > better for use a mirror-like object rather than the actual magic module > objects. > > > > allen > > > > > > > > > > > >> > >> Dave > >> > >> On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> > wrote: > >> > >>> it's not going to be instanceof for various technical reasons. > >>> > >>> I suspect, we can have a isModule predicate function somewhere. > Perhaps, Reflect.isModule or Reflect.Loader.isModule... > >>> > >>> Allen > >>> > >>> > >>> On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: > >>> > >>>> Being able to do `m instanceof Module` is certainly a lot nicer here > though. > >>>> > >>>> Just to return to the consideration of modules as classes, I still > don't understand what the major issue is with having a module as a class > without any prototype methods. > >>>> > >>>> > >>>> On 21 February 2014 00:07, Guy Bedford <guybedford at gmail.com> wrote: > >>>> Thanks John for explaining. As for the usefulness of this path as I > say it is yet to be determined. > >>>> > >>>> Specifically the ability to detect a module instance is needed to > allow ES6 loaders to load AMD that was transpiled from ES6 into AMD. > >>>> > >>>> It may be a little bit of an obscure use case, the exact details of > the use case are described in this gist - > https://gist.github.com/guybedford/5622c9ed5c9ad4bc0417. > >>>> > >>>> The key point being raised here is that there is a scenario in which > detecting a module instance is useful. > >>>> > >>>> > >>>> On 20 February 2014 23:45, John Barton <johnjbarton at google.com> > wrote: > >>>> > >>>> > >>>> > >>>> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock < > allen at wirfs-brock.com> wrote: > >>>> > >>>> On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: > >>>> > >>>>> Thanks, if there is some way to detect this it may well be useful. > >>>>> > >>>>> The use case I came across it was trying to allow ES6 modules to be > transpiled into AMD for use in an ES6 loader. I'm still not sure how > necessary the use case is, but it definitely would need this functionality > work. > >>>> > >>>> The Es6 module loader design has specific hooks to support importing > from foreign module systems. However, I'll leave it to Dave or Sam to > explain how to use them... > >>>> > >>>> Guy is trying to support an important path for JS developers to get > to ES6 and adopt ES module loading: allow developers to mix ES6 and AMD > modules. He already supports loading AMD via ES6-loader. Now he wants to > allow that AMD code to depend upon ES6 modules. This allows AMD teams to > transition smoothly to ES6. He needs something like: > >>>> define(['a', 'b'], function(a, b) { > >>>> if (!(a instanceof Module)) a = { default: a } > >>>> if (!(b instanceof Module)) b = { default: b } > >>>> .... > >>>> so his generated AMD code can accept ES6 modules. > >>>> > >>>> HTH, > >>>> jjb > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> es-discuss mailing list > >>> es-discuss at mozilla.org > >>> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140426/bea7b41a/attachment-0001.html>
If Module objects are not classes, then what would be the recommended way to detect if a given object is a Module?
Would there be a unique toString output?