> 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. I am highly interested by all what is in this paragraph. Would you have articles talking about that you could refer me to?
> > 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. So in a way, are you saying that the DOMCore/WebIDL decision is a bad one? If so, how would you solve the Element+EventTarget problem? One interesting aspect I see in having all the things you inherit from in the [[Prototype]] chain is that you may be able to communicate with all other instances in a way. It may be a completely stupid idea, I don't know. > 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. I don't think I am familiar enough with dynamically typed OO languages to fully grasp how they work and best practices, but if other people are, maybe they should weigh in for another decision for the Element+EventTarget issue. It would be a great occasion to guide the JavaScript community toward using good practices, wouldn't it? I also came from a C/Java background and learnt JS by myself. I'd be happy to learn best practices of dynamic OO languages. As for the first paragraph, if you have articles to share on the topic, I would be happy to read them. David > Allen > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
