I''ve been a bit pinch for time the last couple days, but here are some preliminary responses to a few points below.
On Apr 5, 2011, at 1:38 PM, David Bruant wrote: >> On Apr 2, 2011, at 5:11 PM, Brendan Eich wrote (except the this is really >> quoting Allen Wirfs-Brock): >>> >> 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? Much of the technology and best practices of object-oriented design were developed in the 1990's in the context of developing complex applications and frameworks using Smalltalk. a dynamically typed, single inheritance class based language. There is a large body of work on this topic although most of it is in the guise of Smalltalk. A good resource is http://stephane.ducasse.free.fr/FreeBooks.html which has digitized copies of a number of out of print Smalltalk related books. Pay particular attention to the style guides and patterns related books. You can probably skip the parts the address specific Smalltalk programming idioms (and pitfalls) but pay attention to the parts that are more directly generalizable to other dynamic languages. A highly regarded book that isn't on this site is Kent Beck's Smalltalk Best Practices Patterns. However, with some web searching you may be able to find prepub. drafts that are still floating around the web. For books and articles about OO design methods that were highly influenced by Smalltalk best practices see the work of the other Wirfs-Brock: http://wirfs-brock.com/Resources.html For a book length treatment read: Object Design: Roles, Responsibilities, and Collaborations. Lots of other stuff on the web if you search. > >> >> 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? The EventTarget interface specifies 3 methods addEventListner, removeEventListener, and dispatchEvent. Any object that implements these three methods in conformance to the appropriate DOM spec. conforms to this interface. It doesn't matter if the implementation was inherited or directly implemented on the object. The method that seems to be most essential is dispatchEvent. If I need to test if an object is an EventTarget, I would do it by: if (obj.dispatchEvent) {/* this is an event listener */ ... If you are afraid that somebody might coincidentally implement a method named "dispatchEvent" define a function: function isEventTarget(obj) {return (obj.isDispatchEvent && obj.addEventListner && obj.removeEventListner0 ? true: false)} //personally, I'd seldom, if ever, go to that extreme > > 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. Finding all instances is typically an expensive operations that requires runtime support. It is seldom needed. If you find that you do need it, it is probably a good idea to go back and revisit the design decisions that led to the necessity. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
