I largely agree with Allen's point of approaching classification in a dynamically typed language. I'm also a proponent of divorcing object classification entirely from the inheritance hierarchy. In our traits.js library, we decoupled traits from types, leaving the task of classifying trait-composed objects to the end-user.
One downside of the simple "object marking" scheme using public properties is that it doesn't work for use cases that require a "high-integrity" type test. WeakMaps could help here: a type T can be represented by a WeakMap M. To classify an object as type T, store it as a key in M. To test whether an object o is of type T, look it up in M. If write access to M is properly encapsulated, no object should be able to fool this type test, not even if it's a proxy. Re. proxies & instanceof: no doubt proxies will give rise to a variety of multiple inheritance implementations, but I'm not convinced that the Proxy API should go too much out of its way to be able to emulate concepts that do not exist in the core language. The current strawman (< http://wiki.ecmascript.org/doku.php?id=strawman:proxy_instanceof>) seems to strike a good balance between flexibility and safety. BTW, that strawman would also make it possible to implement syntactically pleasant high-integrity type tests: a type T could be represented by both a WeakMap M and a function proxy F. To test whether an object o is of type T, one can then write the familiar |o instanceof F|, which triggers F's hasInstance trap, which can look up o in M. Cheers, Tom 2011/4/3 Allen Wirfs-Brock <[email protected]> > On Apr 2, 2011, at 5:11 PM, Brendan Eich wrote: > > On Apr 2, 2011, at 4:19 PM, David Bruant wrote: > > > >> I have the feeling that none of these can help out with multiple > inheritance. This is the problem I want to address. > > > > Why? I mean, given the WebIDL and DOM changes. > > > > > >> Is multiple inheritance a use case that TC39 intends to address in a > generic manner? > > > > No. > > Inheritance-based instanceof testing for the purpose of dynamic > classification of objects is most appropriate in statically typed > subclasing===subtyping languages. Multiple inheritance (at least for > interfaces) is almost essential in such languages. That isn't is the case > for dynamically typed subclassing!==subtyping languages. There is lots of > experience with such languages that shows that dynamic classification via > class or superclass inclusion testing is a poor practice. This is because > it is possible (and often even necessary) to create behaviorally > substitutable classes that don't participate in an inheritance > relationship. By using such a test you are forcing downstream developers to > fit into your implementation hierarchy and there may be strong reasons to do > otherwise. > > instanceof testing is very familiar to programmers coming from a Java-like > language background. But like a number of other statically-typed language > practices, instanceof testing is not a good idiom to use in JavaScript. If > an "EventTarget" must have specific behavioral characteristic, then define > those characteristics such that any object that needs to be an "EventTarget" > can implement them, regardless of what is on its [[Prototype]] chain. If it > is important to be able to dynamically test if an object can serve as an > "EventTarget" then define a property that provides that characterization and > make it part of the specified behavior of an "EventTarget". Just don't > require that EventTarget.prototype is somewhere on the [[Prototype]] chain. > > Practically speaking, large parts of JavaScript community are just > starting to use the language to build rich "class" libraries. Many of them > don't have experience with dynamically typed OO languages so they naturally > follow the practices they are familiar with. We really need to guide them > towards using the best practices that have been proven effective for > dynamic OO languages rather than facilitating continued use of static OO > idioms that are a poor fit to JavaScript. > > Allen > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
