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 <al...@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 <al...@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 <guybedf...@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 <johnjbar...@google.com> wrote: >>>> >>>> >>>> >>>> On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock <al...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> >> > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
