RE: Fetch API
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] > Out of curiosity, would you be okay with it if it was just an override? That > is, if "new Response(...)" took either set of arguments for the ... part? It > sounds like you would be. Yeah, I mean, I think in this case it would be kind of awkward for clarity, but from a JS language perspective it's perfectly fine. > This is identically a problem with the case I gave, as > Bar.prototype.constructor would be Foo, not Bar. It's possible that this is > still a problem, it's just not unique to named constructors. ^_^ Since `Foo === Bar` in your case, it's not really a problem. > Since you suggested a static method, that suggests you're fine with Response.Redirect(http://example.com) giving a new Response object, right? It's just the fact that RedirectResponse has a .prototype pointing to Response.prototype that gives you pause? Yeah exactly. (Although it should be lowercase since it's a factory, not a constructor.) > Presumably RedirectResponse being a subtype would also be acceptable, as its > .prototype.constructor would be RedirectResponse? Yeah, although I'm not sure there's a need to override any functionality here, so not sure that there's a need for subclassing.
Re: Fetch API
On Sun, Jun 1, 2014 at 2:19 PM, Domenic Denicola
wrote:
> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
>> Using NamedConstructor is identical to doing:
>>
>> ```js
>> class Foo { ... }
>> let Bar = Foo;
>> // now I can do "new Foo()" or "new Bar()", to the same effect.
>> ```
>
> Not true, since the constructors take different arguments.
Ah right, I forgot that the arguments are different. This effectively
makes it a constructor with overrides, where the function you call it
with is taken as one of the arguments used for discriminating between
overrides.
Out of curiosity, would you be okay with it if it was just an
override? That is, if "new Response(...)" took either set of
arguments for the ... part? It sounds like you would be.
> Instead it is equivalent to
>
> ```js
> class Response {
> constructor(body, init) { ... }
> ...
> }
>
> function RedirectResponse(url, status = 302) {
> return new Response(???, ???);
> }
> RedirectResponse.prototype = Response.prototype;
> ```
>
>> What invariants are you concerned about?
>
> In particular, we have that
>
> ```js
> RedirectResponse.prototype.constructor !== RedirectResponse
> (new RedirectResponse(...)).constructor !== RedirectResponse
> // Also, omitting the `new` does not throw a `TypeError`, like it does for
> real constructors.
> ```
>
> and possibly a few others I am forgetting.
This is identically a problem with the case I gave, as
Bar.prototype.constructor would be Foo, not Bar. It's possible that
this is still a problem, it's just not unique to named constructors.
^_^
Since you suggested a static method, that suggests you're fine with
Response.Redirect(http://example.com) giving a new Response object,
right? It's just the fact that RedirectResponse has a .prototype
pointing to Response.prototype that gives you pause?
Presumably RedirectResponse being a subtype would also be acceptable,
as its .prototype.constructor would be RedirectResponse?
~TJ
RE: Fetch API
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
> Using NamedConstructor is identical to doing:
>
> ```js
> class Foo { ... }
> let Bar = Foo;
> // now I can do "new Foo()" or "new Bar()", to the same effect.
> ```
Not true, since the constructors take different arguments. Instead it is
equivalent to
```js
class Response {
constructor(body, init) { ... }
...
}
function RedirectResponse(url, status = 302) {
return new Response(???, ???);
}
RedirectResponse.prototype = Response.prototype;
```
> What invariants are you concerned about?
In particular, we have that
```js
RedirectResponse.prototype.constructor !== RedirectResponse
(new RedirectResponse(...)).constructor !== RedirectResponse
// Also, omitting the `new` does not throw a `TypeError`, like it does for real
constructors.
```
and possibly a few others I am forgetting.
Re: Fetch API
On 6/1/14, 2:06 AM, Domenic Denicola wrote:
- Named constructors scare me (I can't figure out how to make them work in
JavaScript without breaking at least one of the normal invariants). I think a
static factory method would make more sense for RedirectResponse.
Or just a constructor overload, if the type of "body" for the existing
constructor can be told apart from a string. Which may not be the case,
of course.
- HeaderMap should have a constructor that takes an iterable of [key, value]
pairs, in the same way Map does.
So a sequence> basically, right? Seems pretty
plausible to me.
- I like HeaderMap a lot, but for construction purposes, I wonder if a
shorthand for the usual case could be provided. E.g. it would be nice to be
able to do
fetch("http://example.com";, {
headers: {
"X-Foo": "Bar"
We've had other cases arise where such an "open-ended dictionary"
construct would be useful. The only difference is that those other
cases wanted string-valued keys while this might want ByteString-valued
ones...
One concern here: is order an issue for headers? I seem to vaguely
recall that in practice order can matter with some HTTP servers.
-Boris
P.S. Still reading through; will have feedback of my own in the next
few days.
Re: Fetch API
On Sat, May 31, 2014 at 11:06 PM, Domenic Denicola
wrote:
> - Named constructors scare me (I can't figure out how to make them work in
> JavaScript without breaking at least one of the normal invariants). I think a
> static factory method would make more sense for RedirectResponse.
What invariants are you concerned about? Using NamedConstructor is
identical to doing:
```js
class Foo { ... }
let Bar = Foo;
// now I can do "new Foo()" or "new Bar()", to the same effect.
```
~TJ
Re: WebApp installation via the browser
On 31 May 2014, at 5:00 am, Brendan Eich wrote: > Jeffrey Walton wrote: >> On Fri, May 30, 2014 at 9:04 PM, Brendan Eich wrote: >>> Jeffrey Walton wrote: Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? >>> Firefox OS wants this. >> Thanks Brendan. >> >> As a second related question, is an Installable WebApp considered a >> side-loaded app? > > Sicking can answer with more authority, but side-loaded or downloaded, so > long as the user installs it, no difference. The only difference is the permissions available to the app. Some permissions require a “privileged" app level, and this is only granted to apps installed from the Firefox Marketplace, after security review. This difference only applies to packaged apps - regular web apps (hosted apps) are treated the same no matter where they are installed from. Note that Firefox OS Apps may control which domains may install them by specifying the “installs_allowed_from” manifest property. [1] Developers are also able to side-load apps via the Firefox App Manager, but this is done via the Firefox debugger, and separate to web-based installation. Side-loading allows developers to grant any permissions to their apps, but as stated correctly above, side-loaded apps are not treated any differently once installed. [1] https://developer.mozilla.org/en-US/Apps/Build/Manifest#installs_allowed_from Regards, Paul Theriault > > /be >
Re: WebApp installation via the browser
> On 31 May 2014, at 04:03, "Brendan Eich" wrote: > > Jeffrey Walton wrote: >>> On Fri, May 30, 2014 at 9:04 PM, Brendan Eich wrote: >>> Jeffrey Walton wrote: Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? >>> Firefox OS wants this. >> Thanks Brendan. >> >> As a second related question, is an Installable WebApp considered a >> side-loaded app? > > Sicking can answer with more authority, but side-loaded or downloaded, so > long as the user installs it, no difference. > > /be > A good example of this on FirefoxOS is the (beta) version of the Financial Times WebApp. http://app.ft.com It makes use of the installation API[1] to prompt the user to "install" it if it is not already installed - this is the intended user experience, as a contrast to the "install our app!" interruptive experience on other platforms (has been called "door slam"). The more webbish way is to enable webapps to install themselves on user request - which is what I believe we are trying to enable via the manifest file work. Considering standardization of the installation API may also be worth while. Dan 1. https://developer.mozilla.org/en-US/Apps/Build/JavaScript_API This electronic message contains information from Telefonica UK or Telefonica Europe which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email. Switchboard: +44 (0)113 272 2000 Email: feedb...@o2.com Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85 Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85 Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85
