surely there's nothing to rush about, we survived already until now, no reason to go for a quick solution and mine was just a proposal based on the fact that most of the time contracts are based on primitives.
However, If the problem is typeof null then ES should fix that first but AFAIK it came back to "object" at some point even under "use strict" directive and I never understood why ... primitives also means no wrappers allowed, which is a good practice, generally speaking. However, primitives does not mean "no Classes allowed" 'cause s:string and s:String could be both valid, and different, one typeof, one instanceof, as well as a:Array rather than just a:object where latter one would be permissive while first one will look for instanceof Array. The cross frame is nowadays a non-realworld-problem, I don't know any application that uses direct frames access rather than postMessage or JSONP ... in both cases instanceof Array should simply work ... but of course as long as it's possible to access other frames there could be a problem ... in that case, the function that would like to accept Array from any other window can specify a:object and do the [[Class]] check or use Array.isArray to ensure the type after ... create cross frames problems for a type-hint specification when the cross frame is disappeared from basically every library is a non-sense, imho ... who wants to allow such security problematic contract can use his own check, am I wrong? As summary, string, number, boolean, undefined, function, null, object, as allowed types would cover already many needed cases, adding Array, Object, GenericScopedConstructor, global.name.spaced.Class on top of types can cover 100% of cases I know. Last but not least, if all this won't speed up a thing but actually will decrease JS performances, as Alex pointed out at some point, I would vote for **then don't** no matter what. br
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
