You may have missed the 1JS and typeof null messages. We cannot remove "function" or make any other such backward-incompatible change. But we could add new results. Have a new favorite ;) For others reading this (was hard to find using G, search for ‘ ”One JavaScript” dherman ‘): https://github.com/dherman/tc39-codex-wiki/blob/master/data/about/faq.md The problem with instanceof is that it fails cross frame. Yes, cross frame I didn’t check out yet, but it’s a clear problem...
In the way V.construct prepares a function, it adds a V.Construction Object to the class Function and validates the supplied globalName string to be global evaluable. So for example V.Ex.ArgumentNot Function has a construction property, that will be (new V.Ex.ArgumentNot(‘arg’)).constructor.construction. In that V.Construction Object is the validated globalName stored (as string). To have shorter access, V.construct adds implicit functions to the class function, and also to the prototype for new class objects. The V.Ex.ArgumentNot.constructionOf respectively (new V.Ex.ArgumentNot).instanceOf functions return implicit the globalName, or return a bool if the supplied argument is a valid inherited function-type globalName string. So if I get an ex from another frame, I could check if ex instanceOf(‘V.Ex.ArgumentNot’), if ex instanceof(‘V.Ex.InvalidInstanceof’) or if ex instanceof(‘V.Ex’). I can also check ex.instanceOf === ‘V.Ex.ArgumentNot’. To recreate an object of this type, var fn = V.evalName(‘V.Ex’); var ex = new fn() would re-create a frame-local V.Ex Object. It’s bad... but ways better than typeof. I don’t think typeof should be extended, it always returned lower cased names and not the upper cased string, that would be representative for the primitives global functions (‘object’ and not ‘Object’). The evaluable globalName that V.construct validates is re-expressive. It isn’t only a string, it is a name that evaluated to window points to the class Function. I understand that instanceof won’t be cross-frame capable, however using a global evaluable name, someone who knows that he is talking cross frames may consider using implicit instanceOf([String]) function instead of instanceof Function operator. Uli -----Ursprüngliche Nachricht----- From: Brendan Eich Sent: Sunday, September 30, 2012 1:12 AM To: Uli Riehm Cc: es-discuss Subject: Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes) You may have missed the 1JS and typeof null messages. We cannot remove "function" or make any other such backward-incompatible change. But we could add new results. The problem with instanceof is that it fails cross frame. The invariant two-way implication relating == and === that I gave is important, and for value objects such as int64 and uint64 I argue it implies new typeof results. /be On Sep 29, 2012, at 3:46 PM, "Uli Riehm" <[email protected]> wrote: > I think typeof should be simplified, focusing more on instanceof: typeof > should only return "undefined", "string", "number", "boolean" and "object". > > var fn = function () { }; > fn instanceof Function // true > fn instanceof Object // true > > Because typeof returns a string it is never true for two different types, so > instanceof is more detailed. Problems would be that Null, NotANumber, > Infinity habe to be functions, so that a null can also be instanceof an > Object and a NaN instanceof NotANumber Number Object. Using an Int64 Function > where the prototype is Number, we could also have an instanceof Int64 Number > Object. > > I'm also tweaking around instanceof in my article on > http://metadea.de/V/default.aspx#V_construct_and_your_class ... please see > how I'm creating 'class' functions, having real OOP in jS, using instanceof, > featuring reflection using a V.Construction Object class info (that is also > used for prototyping a base function) and an the implicit instanceOf and > constructionOf functions. Without hacking around __proto__ . > > However I'd like to say that in the part of "Why javaScript typeof operator > should be deprecated" I didn't thought properly about primitives and the > usage of the operators that my idea would completely break ;) So please read > that part with this warning in mind, but there are also some thoughts on > primitives that are boxed to Object. > To say simple what I need to change in the ...deprecated... part is, that > typeof and primitives should keep, but the constructor and the primitives > corresponding Object instances should be the way described. > > Uli >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
