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

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)?

Received on Wednesday, 20 November 2013 20:38:48 UTC