On Oct 14, 2010, at 12:33 PM, Brendan Eich wrote: > Tom, thanks for this, assuming it is an accurate reading of Dmitry's post, > your reply clarifies something for me. When we bridged Java to JS in the > '90s, we had to deal with Java objects having overloaded members. A member > o.m could be an int field or a String -> int method, say.
I meant "int -> String" there, as later context suggests. /be > And methods could be overloaded to take different argument types. > > We implemented something like proxies in C code, and for any overloaded > field, we returned a proxy that could access the int field or call the > String-returning method, depending on context. If called, we tried the > method. If got or set with a number value, we accessed the field. For > overloaded methods we tried disambiguated by JS actual argument type, but > this could fail. There was an elaborate property name, accessibly only via > o["m(i):S"] or some such (I forget the syntax), by which one could > unambiguously name a specific method in the overload. > > But in no case would one want the overloaded member to test as if it were not > present. This may be where Dmitry parts company from us on TC39. Whatever > happens, having methods appear only when invoked is a bug in our view. > . . . _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
