> 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. I agree. That's how I would implement an hasInstance trap too. Not finding a "better" idea is what worries me about this strawman. Currently, instanceof and [[HasInstance]] actually check an "is instance" version in the sense that the object checks whether it has a given object in its prototype chain. What you're describing is an "has instance" in the sense that the constructors looks up to see if it "has an instance" of the object (WeakMap lookup in your example). What I'm worried about is the memory cost of such an implementation. The current [[HasInstance]] implementation has a constant memory cost. Keeping references has a linear memory cost in terms of instance number. My favorite real-world memory-intensive use case is the one-page Standard HTML (http://www.whatwg.org/specs/web-apps/current-work/). Right now, it contains 125684 DOM Elements. If trying to implement EventTarget [[HasInstance]] internal method, it would require as many entries in the WeakMap. Maybe that ES implementors can provide data to say if it sounds like a realistic approach or not, but I'm pessimistic. Depending on the underlying WeakMap implementation, it could also have a noticeable impact on time performance as well. I agree on the flexibility and safety of the approach as you say, but I'm worried about scalability.
Unless we find "smarter" ways to implement the hasInstance trap, it might be a dead-end. If I try to find all the info we can get from an object to test something on it within the hasInstance trap, I can only list: - identity - own properties - [[Prototype]] - [[Extensible]] Storing identities is the WeakMap idea, own properties cannot be relied on to test inheritance, [[Prototype]] is plain old inheritance and it would be silly to provide [[Extensible]] two completely unrelated semantics. Since I don't really know what other information we could extract from an object to test against within the hasInstance trap, I don't really see how it could be used in practice. In a way, my original proposal was an attempt to add another item to the list which would be "equivalence class". Cheers, David > > Cheers, > Tom > > 2011/4/3 Allen Wirfs-Brock <al...@wirfs-brock.com > <mailto:al...@wirfs-brock.com>> > > 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 <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
