Re: [HTML Imports]: what scope to run in

On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma <offler@gmail.com> wrote:

> On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron <waldron.rick@gmail.com>
> wrote:
> >
> >
> >
> > On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> >>
> >> We share the concern Jonas expressed here as I've repeatedly mentioned
> on
> >> another threads.
> >>
> >> On Nov 18, 2013, at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> This has several downsides:
> >> * Libraries can easily collide with each other by trying to insert
> >> themselves into the global using the same property name.
> >> * It means that the library is forced to hardcode the property name
> >> that it's accessed through, rather allowing the page importing the
> >> library to control this.
> >> * It makes it harder for the library to expose multiple entry points
> >> since it multiplies the problems above.
> >> * It means that the library is more fragile since it doesn't know what
> >> the global object that it runs in looks like. I.e. it can't depend on
> >> the global object having or not having any particular properties.
> >>
> >>
> >> Or for that matter, prototypes of any builtin type such as Array.
> >>
> >> * Internal functions that the library does not want to expose require
> >> ugly anonymous-function tricks to create a hidden scope.
> >>
> >>
> >> IMO, this is the biggest problem.
> >>
> >> Many platforms, including Node.js and ES6 introduces modules as a way
> >> to address these problems.
> >>
> >>
> >> Indeed.
> >>
> >> At the very least, I would like to see a way to write your
> >> HTML-importable document as a module. So that it runs in a separate
> >> global and that the caller can access exported symbols and grab the
> >> ones that it wants.
> >>
> >> Though I would even be interested in having that be the default way of
> >> accessing HTML imports.
> >>
> >>
> >> Yes!  I support that.
> >>
> >> I don't know exactly what the syntax would be. I could imagine something
> >> like
> >>
> >> In markup:
> >> <link rel=import href="..." id="mylib">
> >>
> >> Once imported, in script:
> >> new $('mylib').import.MyCommentElement;
> >> $('mylib').import.doStuff(12);
> >>
> >> or
> >>
> >> In markup:
> >> <link rel=import href="..." id="mylib" import="MyCommentElement
> doStuff">
> >>
> >> Once imported, in script:
> >> new MyCommentElement;
> >> doStuff(12);
> >>
> >>
> >> How about this?
> >>
> >> In the host document:
> >> <link ref=import href="foo.js" import="foo1 foo2">
> >> <script>
> >> foo1.bar();
> >> foo2();
> >> </script>
> >>
> >> In foo.js:
> >> module foo1 {
> >> export function bar() {}
> >> }
> >> function foo2() {}
> >
> >
> >
> > Inline module syntax was removed and will not be included in the ES6
> module
> > specification. Furthermore, the example you've illustrated here isn't
> > entirely valid, but the valid parts are already covered within the scope
> of
> > ES6 modules:
> >
> > // in some HTML...
> > <script>
> > import {foo1, foo2} from "foo";
> >
> > foo1();
> > foo2();
> > </script>
> >
> > // foo.js
> > export function foo1() {}
> > export function foo2() {}
> >
> >
> > (note that foo2 isn't exported in your example, so would be undefined)
> >
> > Rick
> >
>
> I thought if an identifier wasn't exported trying to import it would
> result in fast failure (SyntaxError)?
>

Yes, my statement above is incorrect.

Rick