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.
>>
>> I
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 <
a
> 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
wrote:
>
> On A
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 i
> 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,
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 un
On Aug 28, 2014, at 10:10 AM, Ian Hickson 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 W
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
On Fri, Aug 29, 2014 at 5:09 AM, Andrea Giammarchi
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, fo
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 wit
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)`, see
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
recor
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
13 matches
Mail list logo
