Various thoughts... Slipping in support for redefining 'typeof null' feels like the sort of thing I sometimes try to squeeze through ;-)
Why is setTypeOf attached to Function? There would seem to be very little to naturally associate it with Function. I suppose it's because that's where you put 'defineOperator'. Even there, the association with Function seems tenuous. I actually find a stronger association with Math. But really, why aren't these just functions export from the reflection module or some other standard module? Regarding realm associations? What is the rationale for making the typeof binding per realm? I would expect the people would want (at least operator associated) value object instances to be freely used across realms, just like numbers, strings, and booleans are. And I don't think you have mentioned anything about defineOperator creating realm specific operator bindings. So, I would expect that in: x + 1 the value of x may be (for example) a decimal number defined in a different realm and that the + gets appropriately dispatched to do a Decimal+Number add operation. In that case, I would also expect typeof x to give me 'decimal' (or whatever) as registered in the original defining domain. There also seems like a possible consistancy that should maintained between new typeof values and the new Literal Syntax suffix support. Anywhere you can say '0m' you probably should be able to say typeof x == 'decimal. But this seems like it should be lexically scoped rather than Realm scoped. I would argue that Functioun.setTypeOf(null, "null") is actually a different kind of beast and one that you would want to be lexically scoped. The difference is that it is changing the meaning of a pre-existing operator applied to a pre-existing value. This reinterpretation really does need to be scoped only to code that wants to see that change. Also see below: On Jul 28, 2013, at 2:24 PM, Brendan Eich wrote: > Brendan Eich wrote: >> Function.setTypeOf(V, U) >> >> 1. Let S = ToString(U) >> 2. Let T = V >> 3. If T is null then >> 3a. If S is not "null" and S is not "object", throw >> 4. Else >> 4a. If T is not a value object constructor, throw >> 4b. T = T.prototype >> 4c. If TypeofToExemplarMap.has(S), throw >> 5. Call TypeofToExemplarMap.set(S, T) >> 6. Call ExemplarToTypeofMap.set(T, S) > > Correction, see new 4b below: > > 1. Let S = ToString(U) > 2. Let T = V > 3. If T is null then > 3a. If S is not "null" and S is not "object", throw > 4. Else > 4a. If T is not a value object constructor, throw > 4b. If T and Function are not same-realm, throw setTypeOf itself has a realm association so that's what I would expect you would test against. You don't really have access to Function. It might have been passed in as the this value or might not if setTypeOf was invoked via call or been hung-off of a namespace object. But just like setPrototypeOf, I'm not sure that it matters which Realm you retrieved your setTypeOf function from. If each Realm has it's own TypeToExemplarMap than everything will be fine if setTypeOf just gets the map associated with T's (actually V.prototype) Realm. > 4c. T = T.prototype > 4d. If TypeofToExemplarMap.has(S), throw > 5. Call TypeofToExemplarMap.set(S, T) > 6. Call ExemplarToTypeofMap.set(T, S) > > I did not add an exception when the current evaluation context's realm is not > the same as Function's -- that seems too restrictive, forbidding script in > the main window from fixing up typeof for same-origin code that it loads into > an iframe. > > Again, comments welcome (cc'ing Allen since he is realm-master; ES1-5 left > realm implicit and singular, contrary to reality in browsers). > > /be > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
