delegating to typed objects

Kris Zyp 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.
Kris


----- 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.
>
> Yeah.
>
> /be
>
> 




More information about the Es4-discuss mailing list