Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? I'd personally expect `{}.toString.call(new Float32Array([1,2,3]))` to produce same result of `{}.toString.call(Float32Array.prototype)`, seems like the least surprise Regards On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote: Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that throws a TypeError if |this| doesn't have the internal slots of a typed array. Neither %TypedArray%.prototype nor {{Ui,I}nt{8,16,32},Float{32,64}}.prototype have these internal slots. So the builtin Object toString method, called on any of these objects, will throw a TypeError. Is this wise? I suspect there's debugging code out there that expects that toString doesn't throw on at least the typed array prototypes (seeing as it doesn't throw in any engine I'm aware of right now, tho the returned string is inconsistent). This seems like a special case of the general problem that methods, defined on prototype objects, that have dependencies upon instance state such as internal slots or exotic internal methods won't work if applied to their containing prototypes when those prototypes do not provide the expected instance state or behavior. I don't think there is a general solution to this problem. It's a place where the ESs class model is a leaky abstraction. As a special case solution (in support of universal toString support) we could make all such @@toStringTag getters all back to returning Object if the instance requirements they check for are not met. I'd happily accept a bug on that. In an earlier iteration of O.p.toString I was eating exceptions thrown when getting the @@toStringTag value. But that sort of exception suppression wasn't very well received. Allen ___ 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
Re: Question about GetBindingValue
Hello, We found one dead part in ES5 and we're wondering whether we're missing something here. The question is about the 4th step in Section 10.2.1.2.4 GetBindingValue(N, S): 10.2.1.2.4 GetBindingValue(N,S) The concrete Environment Record method GetBindingValue for object environment records returns the value of its associated binding object's property whose name is the String value of the argument identifier N. The property should already exist but if it does not the result depends upon the value of the S argument: 1. Let envRec be the object environment record for which the method was invoked. 2. Let bindings be the binding object for envRec. 3. Let value be the result of calling the [[HasProperty]] internal method of bindings, passing N as the property name. 4. If value is false, then a. If S is false, return the value undefined, otherwise throw a ReferenceError exception. 5. Return the result of calling the [[Get]] internal method of bindings, passing N for the argument. We believe that the 4th step is unreachable. In other words, whenever GetBindingValue(N, S) is called, the result of calling the [[HasProperty]](N) is always true and here's why: Yes, that reasoning looks correct. 10.2.1.1.4 may have a similar problem but we haven't checked it yet. The only immutable bindings present in ES5 are directly initialized before user code can be executed, so yes, step 3 in 10.2.1.1.4 is never reachable in ES5. We checked with the recent ES6 draft but it seems to have the same issue. In ES6 it's actually possible to reach that step (8.1.1.2.6 GetBindingValue, step 5), albeit it's a somewhat tricky and involves doing unusual things with proxy objects: ```javascript with(new Proxy({}, { has: function(t, name) { print(has: +name); return !this.called (this.called = true); }})) { (function(){ use strict; ref })(); } ``` That program will give the following output: --- has: ref has: ref uncaught exception: ReferenceError: cannot resolve reference: ref --- Proxy objects allow you to define your own [[HasProperty]] implementation (the has method in the example above). In this case [[HasProperty]] will return `true` on the first call in order to report a binding is present in HasBinding, but then will return `false` when the binding's presence is checked the second time in GetBindingValue. Best, -- Sukyoung ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
On Aug 29, 2014, at 3:09 AM, Andrea Giammarchi wrote: Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? I'd personally expect `{}.toString.call(new Float32Array([1,2,3]))` to produce same result of `{}.toString.call(Float32Array.prototype)`, seems like the least surprise Why one is a TypedArray instance and the other is an ordinary object. BTW, another way to approach this issue would be to include the equivalent of: ```js if (this.constructor.prototype === this) return Object ``` in the @@toStringTag getter for such classes. Allen Regards On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote: Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that throws a TypeError if |this| doesn't have the internal slots of a typed array. Neither %TypedArray%.prototype nor {{Ui,I}nt{8,16,32},Float{32,64}}.prototype have these internal slots. So the builtin Object toString method, called on any of these objects, will throw a TypeError. Is this wise? I suspect there's debugging code out there that expects that toString doesn't throw on at least the typed array prototypes (seeing as it doesn't throw in any engine I'm aware of right now, tho the returned string is inconsistent). This seems like a special case of the general problem that methods, defined on prototype objects, that have dependencies upon instance state such as internal slots or exotic internal methods won't work if applied to their containing prototypes when those prototypes do not provide the expected instance state or behavior. I don't think there is a general solution to this problem. It's a place where the ESs class model is a leaky abstraction. As a special case solution (in support of universal toString support) we could make all such @@toStringTag getters all back to returning Object if the instance requirements they check for are not met. I'd happily accept a bug on that. In an earlier iteration of O.p.toString I was eating exceptions thrown when getting the @@toStringTag value. But that sort of exception suppression wasn't very well received. Allen ___ 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
Re: Question about GetBindingValue
On Aug 29, 2014, at 4:07 AM, André Bargull wrote: ... We checked with the recent ES6 draft but it seems to have the same issue. In ES6 it's actually possible to reach that step (8.1.1.2.6 GetBindingValue, step 5), albeit it's a somewhat tricky and involves doing unusual things with proxy objects: ,,, Proxy objects allow you to define your own [[HasProperty]] implementation (the has method in the example above). In this case [[HasProperty]] will return `true` on the first call in order to report a binding is present in HasBinding, but then will return `false` when the binding's presence is checked the second time in GetBindingValue. And in ES5, host object have similar capabilities. I believe we put this checks in specifically to make sure everything was well defined in the presence of such host objects. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
On Fri, Aug 29, 2014 at 5:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? It is inconsistent, but it's a change TC39 deliberately chose to take. It's a good change. The fact that Date.prototype is a real Date object, for example, has been a common source of bugs and general weirdness. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have settled on using Object.prototype.toString.call as a way to determine the kind of a value and don't expect that to throw. This is edge case but it seems like an unnecessary gotcha to throw at devs. - JDD On Fri, Aug 29, 2014 at 11:57 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Fri, Aug 29, 2014 at 5:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? It is inconsistent, but it's a change TC39 deliberately chose to take. It's a good change. The fact that Date.prototype is a real Date object, for example, has been a common source of bugs and general weirdness. -j ___ 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
Re: ES6 Loader proposed changes
On Aug 28, 2014, at 10:10 AM, Ian Hickson i...@hixie.ch wrote: Here are the changes that would be needed to make the ES6 loader infrastructure underpin the Web platform's loader infrastructure (basically, placing the ES6 loader the management layer between the Web platform APIs on top, and Service Workers underneath). ... If we can reuse this for the rest of the Web platform, it gives authors a really uniform API for all loading operations. The module loader isn't the right layer for the kinds of things you're trying to do. I understand you're trying to avoid having similar mechanisms at multiple layers of the platform, but repurposing the module loader system as a general purpose web resource loading system means conflating web resources and modules, which leads to a mixing of concerns exposed to the development model. Let me go into some more detail. ## What the `System` module loader is for First, let's talk about what the module loader *is* for, and what the important requirements the browser's default `System` loader should address. In particular, I'm *not* saying that there should be *no* reflection of web assets to the JS module system. ### JS module name resolution * *Basic name resolution for JS modules.* Refer to global and relative modules. * *Module naming conventions that work across JS ecosystems.* Conventions that work on both client and server, particularly with npm. Straw-examples: ```javascript import _ from underscore; // global module import spinner from ./spinner.js; // relative module ``` ### HTML interop * *Making JS modules available to HTML.* Allow HTML files to import from JS. Straw-examples: ```html !-- for now: -- script type=module import $ from jquery; import frobify from /scripts/frobify.js; $(.frob).each((i, elt) = { frobify(elt); }); /script !-- eventually, but we can save this discussion for another day: -- module import $ from jquery; // etc. /module ``` * *Reflecting web assets as JS modules.* Make web assets available to JS as modules that export a DOM element. Straw-example: ```javascript import icon from ./icon.png; console.log(icon instanceof HTMLImageElement); // true ``` ### Installing HTML/CSS components via module import * *Applying CSS via import.* Mechanism for applying stylesheets by importing them from JS. Straw-example: ```javascript import ./main.css; // guarantees CSS is loaded and applied by the time this module executes import $ from jquery; $(#main).show(); ``` * *Installing HTML imports via import.* Mechanism for installing HTML imports by importing them from JS. Straw-example: ```javascript import widget from ./widget.html; console.log(widget instanceof DocumentFragment); // true ``` ### Enriched response API * *Cross-origin fetch.* Cross-origin requests should succeed by returning and opaque response, just as ServiceWorker does, that cannot be inspected but can be returned back into the pipeline for execution. * *Streaming fetch.* It should be possible for a request to return a stream instead of a string, to allow asynchronous stream processing; this should use the API that results from the stream standardization process. ## What the `System` module loader is NOT for * *Bundling requests.* While it's attractive to use the loader for serving multiple assets in a single payload, this wants a more general solution for bundling arbitrary assets -- perhaps for performance (since despite the impending coolness of HTTP2, people will likely still use bundling as a successful optimization technique for a long time), but also for ergonomic deployment and inclusion. Jeni Tennison has done an excellent [proposal based on the link tag](https://github.com/w3ctag/packaging-on-the-web), and I've started exploring another approach based on URLs. Meanwhile people can experiment in userland with ServiceWorker-based techniques for bundling payloads. * *Repurposing the module registry to reflect caching of arbitrary browser fetches.* The registry is meant to record installation of things that are conceptually modules, not arbitrary network fetches of web assets. It's not the right place to store a cache of fetches. In particular, notice how above I said that it makes sense for modules to be able to import from, say, PNG files. In that case, the developer has explicitly requested that a web resource be reflected as a module, and it should be installed as a module. But using the registry for all web fetches means that non-JS is polluting the module registry with random modules reflecting arbitrary assets in the application. * *Forcing resource management to be reflected as modules.* The ServiceWorker API gives programmatic control over fetching of network payloads and a caching API. The module loader API gives programmatic control over fetching of modules and a caching API. What you're describing is using the latter for programmatic control over fetching and caching web assets, but that
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
On Aug 29, 2014, at 12:10 PM, John-David Dalton wrote: JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have settled on using Object.prototype.toString.call as a way to determine the kind of a value and don't expect that to throw. This is edge case but it seems like an unnecessary gotcha to throw at devs. We've explicitly designed the ES6 O.p.toString to preserve the [[Class]] type branding that was proved by prior editions but also decided to explicitly not support any new primitive [[Class]]-like brand values. Going forward it isn't a reliable way to type check or brand new built-in or programmer defined types. I will fix the handful of standard @@toStringTag getters so they don't throw. But I can't really really do anything about user written @@toStringTag getter that throw or for that matter objects that use Proxies to throw. So, unless you wan to argue for eating exceptions in O.P.toStringm, that possibility will remain but is likely the reflection of a bug or malicious code. Presumablly, such problems can be diagnosed via a debugger allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
I will fix the handful of standard @@toStringTag getters so they don't throw That's rad! But I can't really really do anything about user written @@toStringTag getter that throw or for that matter objects that use Proxies to throw. Ya, that's fine. - JDD On Fri, Aug 29, 2014 at 1:58 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 29, 2014, at 12:10 PM, John-David Dalton wrote: JS libs/frameworks (jQuery, Dojo, Lo-Dash, Ember, Angular, ...) have settled on using Object.prototype.toString.call as a way to determine the kind of a value and don't expect that to throw. This is edge case but it seems like an unnecessary gotcha to throw at devs. We've explicitly designed the ES6 O.p.toString to preserve the [[Class]] type branding that was proved by prior editions but also decided to explicitly not support any new primitive [[Class]]-like brand values. Going forward it isn't a reliable way to type check or brand new built-in or programmer defined types. I will fix the handful of standard @@toStringTag getters so they don't throw. But I can't really really do anything about user written @@toStringTag getter that throw or for that matter objects that use Proxies to throw. So, unless you wan to argue for eating exceptions in O.P.toStringm, that possibility will remain but is likely the reflection of a bug or malicious code. Presumablly, such problems can be diagnosed via a debugger allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Loader proposed changes
On Fri, 29 Aug 2014, David Herman wrote: It's still not completely clear to me what your use cases are, so I'm not sure exactly how much user-visible API you need. My goal is to avoid browsers having to implement two dependency systems (one for ES modules, one for HTML imports). But if you are trying to reflect the browser's fetching policies and priorities based on different types of assets, then you are looking for a layer in between ServiceWorker and module loader -- call it an asset manager or resource manager. Right. But that kind of system will have dependencies to track, including dependencies between ES6 modules, and on ES6 modules from other things, and from ES6 modules to other things. I don't understand how to make that work if we're not able to have a single dependency system. I'd be happy to discuss this with you and see if we can flesh out the use cases and requirements to get a better handle on the problem space. I would love that. Where and when? You may also find the following helpful in explaining things I'm looking at at the moment related to this: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
one is a TypedArray instance and the other is an ordinary object. let me try again ... Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? Isn't String.prototype an ordinary object ? On Fri, Aug 29, 2014 at 4:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 29, 2014, at 3:09 AM, Andrea Giammarchi wrote: Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? I'd personally expect `{}.toString.call(new Float32Array([1,2,3]))` to produce same result of `{}.toString.call(Float32Array.prototype)`, seems like the least surprise Why one is a TypedArray instance and the other is an ordinary object. BTW, another way to approach this issue would be to include the equivalent of: ```js if (this.constructor.prototype === this) return Object ``` in the @@toStringTag getter for such classes. Allen Regards On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote: Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that throws a TypeError if |this| doesn't have the internal slots of a typed array. Neither %TypedArray%.prototype nor {{Ui,I}nt{8,16,32},Float{32,64}}.prototype have these internal slots. So the builtin Object toString method, called on any of these objects, will throw a TypeError. Is this wise? I suspect there's debugging code out there that expects that toString doesn't throw on at least the typed array prototypes (seeing as it doesn't throw in any engine I'm aware of right now, tho the returned string is inconsistent). This seems like a special case of the general problem that methods, defined on prototype objects, that have dependencies upon instance state such as internal slots or exotic internal methods won't work if applied to their containing prototypes when those prototypes do not provide the expected instance state or behavior. I don't think there is a general solution to this problem. It's a place where the ESs class model is a leaky abstraction. As a special case solution (in support of universal toString support) we could make all such @@toStringTag getters all back to returning Object if the instance requirements they check for are not met. I'd happily accept a bug on that. In an earlier iteration of O.p.toString I was eating exceptions thrown when getting the @@toStringTag value. But that sort of exception suppression wasn't very well received. Allen ___ 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
Re: Object.prototype.toString.call(Uint8Array.prototype) throws a TypeError
in case my question wasn't clear ... `String.prototype instanceof String` is `false` and `typeof String.prototype` is `object` So, my concern, and the least surprise I was talking about, are still there. Feel free to ignore though Regards On Fri, Aug 29, 2014 at 11:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: one is a TypedArray instance and the other is an ordinary object. let me try again ... Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? Isn't String.prototype an ordinary object ? On Fri, Aug 29, 2014 at 4:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 29, 2014, at 3:09 AM, Andrea Giammarchi wrote: Wouldn't that be inconsistent with `{}.toString.call(String.prototype)` and all others ? I'd personally expect `{}.toString.call(new Float32Array([1,2,3]))` to produce same result of `{}.toString.call(Float32Array.prototype)`, seems like the least surprise Why one is a TypedArray instance and the other is an ordinary object. BTW, another way to approach this issue would be to include the equivalent of: ```js if (this.constructor.prototype === this) return Object ``` in the @@toStringTag getter for such classes. Allen Regards On Fri, Aug 29, 2014 at 1:44 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 28, 2014, at 2:56 PM, Jeff Walden wrote: Per latest draft, %TypedArray%.prototype[@@toStringTag] is a getter that throws a TypeError if |this| doesn't have the internal slots of a typed array. Neither %TypedArray%.prototype nor {{Ui,I}nt{8,16,32},Float{32,64}}.prototype have these internal slots. So the builtin Object toString method, called on any of these objects, will throw a TypeError. Is this wise? I suspect there's debugging code out there that expects that toString doesn't throw on at least the typed array prototypes (seeing as it doesn't throw in any engine I'm aware of right now, tho the returned string is inconsistent). This seems like a special case of the general problem that methods, defined on prototype objects, that have dependencies upon instance state such as internal slots or exotic internal methods won't work if applied to their containing prototypes when those prototypes do not provide the expected instance state or behavior. I don't think there is a general solution to this problem. It's a place where the ESs class model is a leaky abstraction. As a special case solution (in support of universal toString support) we could make all such @@toStringTag getters all back to returning Object if the instance requirements they check for are not met. I'd happily accept a bug on that. In an earlier iteration of O.p.toString I was eating exceptions thrown when getting the @@toStringTag value. But that sort of exception suppression wasn't very well received. Allen ___ 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
Re: Question about GetBindingValue
Thank you all for your answers! Your answers were really helpful. Best, -- Sukyoung On Aug 30, 2014, at 12:34 AM, Allen Wirfs-Brock wrote: On Aug 29, 2014, at 4:07 AM, André Bargull wrote: ... We checked with the recent ES6 draft but it seems to have the same issue. In ES6 it's actually possible to reach that step (8.1.1.2.6 GetBindingValue, step 5), albeit it's a somewhat tricky and involves doing unusual things with proxy objects: ,,, Proxy objects allow you to define your own [[HasProperty]] implementation (the has method in the example above). In this case [[HasProperty]] will return `true` on the first call in order to report a binding is present in HasBinding, but then will return `false` when the binding's presence is checked the second time in GetBindingValue. And in ES5, host object have similar capabilities. I believe we put this checks in specifically to make sure everything was well defined in the presence of such host objects. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss