On Mon, Nov 3, 2008 at 10:55 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> I'm sure people may have an opinion one way or the other, I just don't know > of any Web content actually broken by this in practice. I don't have strong > feelings on the matter in either direction, just reporting our experience. > For Cajita, the only issue is RegExps. Host objects are such a disaster of unspecified vagueness and random browser behavior that we never expose hosts objects directly to cajoled code. Rather, we intermediate all access to host objects through our taming layer. Other secure JS variants -- ADsafe, FBJS, Jacaranda, MS WebSandbox, dojox.secure -- do likewise. Within Cajita, RegExps are non-callable and are not functions, irrespective of the underlying JS's behavior. Therefore, within Cajita, |typeof F === 'function'| iff the [[Class]] property of F is "Function". In Cajita, therefore, there is no difference between "being callable" and "being a function". Because Rhino and WebKit say that typeof a RegExp is 'function', we need to translate all Cajita typeof operations. Because Valija -- the full ES3.1-strict emulation layer build on Cajita -- uses typeof in performance critical places, this translation turned out to be costly. ********** I suggest that, for non-host objects, we change the ES3.1 spec so that |typeof F === 'function'| iff the [[Class]] property of F is "Function". For host objects, the spec would continue to allow them to return whatever the func they want ;). This proposed change is acceptable to all participants on this morning's ES3.1 call, pending your reactions on these lists. ********** Practically, the only difference this will make is to mandate that typeof a RegExp be "object", not "function", whether or not RegExps are callable on that platform. Given that this matches IE's and FF's current behavior, this change will not break the web. This would have the unpleasant consequence of causing WebKit and Rhino to become out of conformance with ES3.1 because they correctly implemented this clause of ES3. If they do not object, does anyone see any other downsides to this suggestion? -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
