github at esdiscuss.org (2013-07-12T02:27:21.592Z)
On 4 May 2013 01:46, Jason Orendorff <jason.orendorff at gmail.com> wrote:
> On Thu, May 2, 2013 at 9:47 AM, Andreas Rossberg <rossberg at google.com> wrote:
>> I don't see how logical names can possibly make sense without at least
>> a rudimentary manager that maps them. Otherwise they are just physical
>> names.
>
> Yes. A rudimentary way of mapping logical names to URLs is built into
> the proposal: the default resolve behavior.
>
> 0) No effort: modules are loaded relative to the document base url,
> with ".js" appended. So `import "jquery"` maps to the relative URL
> `"jquery.js"`.
>
> 1) One line of code: you can set the root URL from which all imports
> are resolved. If you set `System.baseURL = "https://example.com/scripts/"` then `import "jquery"` maps to the URL
> `"https://example.com/scripts/jquery.js"`.
>
> 2) A few lines: you can use `System.ondemand()` to set the URL for each
> module you use. If you call
> `System.ondemand({"https://example.com/jquery-1.9.1.js": "jquery"})`
> then `import "jquery"` maps to the URL you specified (imports for
> modules that aren't in the table will fall back on the loader's
> baseURL).
>
> 3) Beyond that: write a resolve hook and locate modules however you want.
Option 0 only applies if a specific design choice for the syntax of
logical names is already hardwired into the default resolver logic.
You assume that syntax to be plain path names, but as I tried to point
out in my previous replies, interpreting plain "jquery" as a logical
name is simply not an option in the current set-up, since it
fundamentally violates URL semantics -- allowing URLs in imports, and
using plain paths as global logical names, are mutually exclusive
design choices. So you have to distinguish logical names syntactically
somehow, and map that syntax in the resolver. I'd prefer the language
not to prescribe a specific syntax for that, since actual package
managers might want to make their own choices.
All other options additionally require staging. That is, it will be
more than just one line, and you need to run it in a separate set-up
script. At that point you arguably have implemented a rudimentary
manager, i.e., it's not just built in -- which, to be clear, I find
perfectly fine.
/Andreas
On 4 May 2013 01:46, Jason Orendorff <jason.orendorff at gmail.com> wrote: > On Thu, May 2, 2013 at 9:47 AM, Andreas Rossberg <rossberg at google.com> wrote: >> I don't see how logical names can possibly make sense without at least >> a rudimentary manager that maps them. Otherwise they are just physical >> names. > > Yes. A rudimentary way of mapping logical names to URLs is built into > the proposal: the default resolve behavior. > > 0. No effort: modules are loaded relative to the document base url, > with ".js" appended. So `import "jquery"` maps to the relative URL > "jquery.js". > > 1. One line of code: you can set the root URL from which all imports > are resolved. If you set `System.baseURL = > "https://example.com/scripts/"` then `import "jquery"` maps to the URL > "https://example.com/scripts/jquery.js". > > 2. A few lines: you can use System.ondemand() to set the URL for each > module you use. If you call > `System.ondemand({"https://example.com/jquery-1.9.1.js": "jquery"})` > then `import "jquery"` maps to the URL you specified (imports for > modules that aren't in the table will fall back on the loader's > baseURL). > > 3. Beyond that: write a resolve hook and locate modules however you want. Option 0 only applies if a specific design choice for the syntax of logical names is already hardwired into the default resolver logic. You assume that syntax to be plain path names, but as I tried to point out in my previous replies, interpreting plain "jquery" as a logical name is simply not an option in the current set-up, since it fundamentally violates URL semantics -- allowing URLs in imports, and using plain paths as global logical names, are mutually exclusive design choices. So you have to distinguish logical names syntactically somehow, and map that syntax in the resolver. I'd prefer the language not to prescribe a specific syntax for that, since actual package managers might want to make their own choices. All other options additionally require staging. That is, it will be more than just one line, and you need to run it in a separate set-up script. At that point you arguably have implemented a rudimentary manager, i.e., it's not just built in -- which, to be clear, I find perfectly fine. /Andreas