Le 06/04/2011 08:14, Allen Wirfs-Brock a écrit : > 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 > <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. Sorry I was inaccurate in what I said. What I meant is here: https://gist.github.com/905301 c1 and c2 (and all objects created through getInstance) can "communicate" through their prototype: in this case, only with an access to c1 (from anywhere in the program), I can create a "c" property available in all other "instances". And it doesn't require to know any other instance (nor all instances consequently). If created with a constructor, it wouldn't even require access to the contructor itself. Calls to Object.getPrototypeOf are enough (one call in my example, but the technique could scale up as you can imagine). In this "prototype-based communication pattern", the prototype chain shape matters a lot. If all EventTarget instances have their methods as own, you can't climb the prototype chain to implement the mechanism I have just exposed.
Thanks for all the readings, David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
