On Dec 27, 2011, at 10:29 AM, David Bruant wrote: > Le 27/12/2011 19:14, Mark S. Miller a écrit : >> >> On Tue, Dec 27, 2011 at 7:15 AM, David Bruant <[email protected]> wrote: >> ... >> That's what I wish. JS already has name-based polymorphism (as is typical of >> scripting languages). Generic methods, such as those from Array.prototype, >> are only appropriate when the actions of the generic method can itself be >> fully described in terms of accessing other publicly available properties by >> name-based lookup. In this case, get/set/has/delete is the lowest level >> publicly available interface, and their semantics is defined in terms of >> accessing internal encapsulated properties. In this regard, they are more >> like the Date.prototype methods. The fact that similar operations have the >> same names is all the polymorphism these need or should have. > Very interesting point. > > Currently, the Date.prototype method throw a TypeError (ES5.1 - 15.9.5 > introductory section). The same is probably expected when trying map > operations on weakmap (etc.) ? >
I think there are two separate issues here. Polymorphic application of methods and implementation inheritance via subclassing. You would only expect polymorphic application of methods (such as in David's example) to work if the target object has an internal implementation that conforms to the expectation of the specific method that is being invoked. In most OO languages, this will frequently be the case if the target object is a "subclass" of the object that defines the method. It often will not be the case if the target object is not such a "subclass". The date methods throw a type error in ES5.1 because they essentially requires a specific internal implementation details of instance objects and those implementation details can not be given to any other objects. Not even objects that inherit from Date.prototype or other Date instances. For ES.next we already have a plan to modify the spec. for Date in a manner that allows "subclasses" of Date to share these date implementation details and hence allows the inherited Date.prototype instances to operate correctly on such "subclass" instances. Given this perspective. It seems that an open question for ES.next is whether or not Map and WeakMap are "subclassable". I propose that they should be (but note that neither is a subclass of the other) and that we should take care to specify them in a manner that ensures that. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
