Re: Cross-global instanceof
What are the use cases for things like 'isGenerator'. When and why would you need to know that an object upon which you are going to invoke the Iterator interface was/wasn't implemented by a generator. [`co`][1] is a library similar to Task.js that allows you to use ES6 generators as async / await. It allows you to yield multiple different types of future values and uses polymorphic dispatch to the correct await implementation based on type checks. Here there is a genuine use case for overloading yield to implement an async / await DSL that does the correct thing basd on the type of future value that you yield within the generator. In it's implementation it uses `isGenerator` and `isGeneratorFunction` ( https://github.com/visionmedia/co/blob/master/index.js#L153 ). I also personally use an `isGenerator` function ( https://github.com/Raynos/gens/blob/master/index.js#L43 ) so that I can implement the correct await semantics for the different types of future values you are allowed to yield in my library `gens` [1]: https://github.com/visionmedia/co/blob/master/index.js#L153 On Thu, Oct 31, 2013 at 11:01 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Oct 31, 2013, at 9:43 AM, Brandon Benvie wrote: On 10/31/2013 8:50 AM, David Bruant wrote: I'm not sure it's worth making it work for jQuery. This is trying to make a good use of same-origin multi-global which shouldn't exist in the first place. Keeping same-origin access as it is and encouraging people to add @sandbox even on same-origin iframes seems like a better idea. Should the addition be a nicer Object.prototype.toString.call? You're right, it's not instanceof. But I definitely think the argument can be made that there is a need for checking if something is of a certain class. I'm finding myself wanting things like `isGenerator` and `isGeneratorFunction`, for example. There's countless examples of people re-purposing Object.prototype.toString to serve this functionality ad hoc. What are the use cases for things like 'isGenerator'. When and why would you need to know that an object upon which you are going to invoke the Iterator interface was/wasn't implemented by a generator. If the reason is to know whether or not you can use the throw method (the only real difference between the generator object interface and the Iterator interface) you can test: 'throw' in possibleGenerator In general this sort of isFoo or obj.constructor === Foo class test is a bad smell in dynamic class based languages and tends to be a reflection of static nominal type thinking (which is fine in its own context, but JS is has a dynamic class model). 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: Cross-global instanceof
Le 02/11/2013 03:13, Allen Wirfs-Brock a écrit : On Nov 1, 2013, at 6:05 PM, David Bruant wrote: I'm not sure about proxy returning Proxy as tag name. Is that a good idea? Brand feels like something that could safely transparently cross proxies. There is a note on in the ES6 draft on that Proxy case of O.P.toStirng that says: This could be used an isProxy test. Do we really want that? Nobody has answered that question yet? What do you mean by band transmitted accross proxies. ES6 has no general concept of brand. lousy language, my mistake. I meant @@toStringTag. We could handle that case by internally doing O.p.toString.cal(this.[[target]]) for the proxy case. Or we could just turn it into this.toString(). But neither of those seem particularly correct, in general. Or we could simply not special case Proxy exotic objects and then Proxies would be handled like any other object, the value of the objects @@toStringTag property would be accessed and used to compose the toString result. Or what about a third optional argument to the Proxy constructor to set the @@toStringTag? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Cross-global instanceof
On Nov 1, 2013, at 7:13 PM, Allen Wirfs-Brock wrote:
On Nov 1, 2013, at 6:05 PM, David Bruant wrote:
Le 02/11/2013 01:08, Brandon Benvie a écrit :
On 11/1/2013 4:59 PM, Brandon Benvie wrote:
On 11/1/2013 4:31 PM, Brandon Benvie wrote:
In the spec for Object.prototype.toString:
'If tag is any of Arguments, Array, Boolean, Date, Error,
Function, Number, RegExp, or String and SameValue(tag,
builtinTag) is false, then let tag be the string value ~ concatenated
with the current value of tag.'
An interesting consequence of this is that a Proxy for any of these will
default to being ~ + target class. So
`Object.prototype.toString.call(new Proxy([], {}))` is [object ~Array].
But it seems the shipped has already sailed on Proxies being conspicuously
not interchangeable with their targets in many cases...
Actually that's incorrect. Proxies explicitly will return Proxy for their
tag. Same problem though.
In what other ways the ship has sailed?
At least regular objects and arrays can be faithfully interchanged I think,
no? Things get complicated with Date/WeakMap/etc because of private state,
but I remain hopeful a solution can be found in the ES7 timeframe (or
whatever the next iteration is called).
Note, proxies do not transparently operate on target objects that have
private internal state or any sort of internal dependencies upon object
identify. You can define a handler that over-rides most of the traps and
make it work, but for most built-ins doing something like:
Proxy (new Date, {} )
will give you an object that throws when methods of the target object are
invoked upon it.
I just realized that the current specification of O.p.toString is a example of
a method that has a identity dependency and hence won't work with default Proxy
forwarding. As currently specified,
Proxy({}, {}).toString()
would yield [object Proxy] rather than [object Object] as you (and I) might
have expected. The reason is that the default handler will lookup toString
using the target object's [[Prototype]] chain and find the implementation in
Object.prototype. But when it invokes that method the default handler will
pass the Proxy object rather than the target object of the this value. Hence:
[[object Proxy]].
This seems too wrong to me, but I'm not yet clear on an appropriate fix within
O.p.toString.
I'm not sure about proxy returning Proxy as tag name. Is that a good idea?
Brand feels like something that could safely transparently cross proxies.
There is a note on in the ES6 draft on that Proxy case of O.P.toStirng that
says: This could be used an isProxy test. Do we really want that? Nobody
has answered that question yet? What do you mean by band transmitted
accross proxies. ES6 has no general concept of brand.
Note, that the Proxy proposal originally came with a Proxy.isProxy function and
after various discussions (for example,
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015935.html ) it was
removed. An brand check approach that that identifies Proxies (including the
current spec. for O.p.toString) is a backdoor way of implementing
Proxy.isProxy. If the reasons for removing Proxy.isProxy are valid then we
should be providing such a backdoor.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Cross-global instanceof
On Sat, Nov 2, 2013 at 10:55 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: [...] If the reasons for removing Proxy.isProxy are valid then we should be providing such a backdoor. not? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Cross-global instanceof
On Nov 2, 2013, at 11:25 AM, Mark S. Miller wrote: On Sat, Nov 2, 2013 at 10:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: [...] If the reasons for removing Proxy.isProxy are valid then we should be providing such a backdoor. not? shouldn't -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: computed property keys and ES5 duplicate rule enforcement
On Oct 25, 2013, at 7:49 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It turns out that even in pseudo code, this is a fairly complicated set of
runtime validation rules to apply. I'm having a hard time convincing myself
that the runtime computational and meta data costs of this dynamic validation
is justified. It costs too much and the actual benefit is pretty small.
***For that reason, I propose that we drop this runtime validation of object
literals (and class definition). We would still have the static validation
and early errors for property definitions that don't have computed keys. But
anything that makes it past those checks (including all property definitions
with computed names) are just processed sequentially with no duplicate name
checking.***
Yep, I fully agree. And I especially appreciate what you say below:
What about predetermining the shape of literal objects that include
computed property keys?
One of the reason for the dynamic checks was the desire to preserve the
characteristics that allowed an implementation to look at an object literal
and statically determine exactly how many own properties the resulting
objects would have. The hope was that an implementation could still
determine an intended shape and that the dynamic checks would guarantee that
the actual constructed objects conform to that predicted shape. If we drop
the dynamic checks we loose that shape guarantee.
I think this ability to predict an intended shape was probably a committee
pipe-dream.
Amen.
Consider this function:
function makeObj(a,b,c,d,e) {
return {
get [a] () {},
get [b] () {},
set [c] (v) {},
set [d] (v) {},
set [e] (v) {}
}
}
The object returned by this function might validly have 3, 4, or 5
properties. The is no clearly intended shape to try to guarantee.
The shape predictability concept has never really been defined clearly, and
this is a good demonstration of why it's fishy.
Anyway, agreed 100%. It's worth revisiting at the November f2f.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
