delegating to typed objects
kriszyp at xucia.com
Mon Jul 9 21:09:53 PDT 2007
I think it seems worth considering what a programmer is intending if writes
a function and defines a prototype for it. This is an explicit action to
create objects that inherit from the prototype object. If a user has
specifically written code to inherit from c, wouldn't he expect to inherit
everything from c, including fixtures and methods (that work, not throw
incompatibility errors)? If we access fixture properties and methods just as
we do do expando properties and functions, why wouldn't we expect
programmers to want and fixtures and methods to be inherited? Defining
prototypes is not something that just automatically happens in places, but
is a very intentional definition on the part of a programmer in which they
want and expect inheritance.
And I still appeal to the symmetry and consistency of the "is" operator
operating exactly the same as the old instanceof operator when the testing
against a class:
(a is C) == C.prototype is in a's delegate chain (at least when __proto__
has not been externally modified) that would be true with option 1.
----- Original Message -----
From: "Brendan Eich" <brendan at mozilla.org>
To: "Kris Zyp" <kriszyp at xucia.com>
Cc: <es4-discuss at mozilla.org>; "Jeff Dyer" <jodyer at adobe.com>
Sent: Monday, July 09, 2007 5:00 PM
Subject: Re: delegating to typed objects
> On Jul 9, 2007, at 4:51 PM, Kris Zyp wrote:
>> You are right, it doesn't work for a Date, but it does work on an Array.
> Only if you don't call toString or toLocaleString.
> Most Array and String prototype methods are intentionally generic. Too
> bad we didn't generalize this all over the place in 1996 (sorry, Tucker).
> To call such methods on other types of objects, in ES1-3 you have to use
> .apply or .call -- in ES4 there are Array.slice, .e.g., counterparts that
> take a leading explicit this-object parameter for Array.prototype.slice.
>> The incompatibility of calling setTime on the Date instance seems to
>> have more to do with the natural inclination to make primitives classes
>> "final" (I am not sure if they are in ES4, but in Java they are final)
>> than class method binding. While I am still hoping for option 1, I will
>> say that throwing an (incompatible object) error on f.m() seems more
>> consistent than the other possibilites that I have been countering:
>> non-shallow assignments, automatic this- binding, or preventing the
>> assignment of prototype objects that happen to be instances of user
>> defined classes.
More information about the Es4-discuss