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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
