The ES3 spec already specifies the specific prototype of each built-in object 
and their instances. However, when it comes to implementing built-in objects or 
for that matter user defined objects there is nothing that prevents an 
implementation from using "invisible" intermediate prototypes for whatever  
purposes it finds useful.  Those, of course, would not be visible to a 
getPrototypeOf function.

Penetrating an implementation encapsulation barrier whether at the "engine", 
library, or framework level always carries with it the risk of introducing 
implementation dependencies. That doesn't mean there aren't good reasons for 
doing so, you just better know what you're doing and use appropriate care.   
The static Object methods are intend for use by people who know what they are 
doing. Certainly, there is an attractive nuisance factor that will get some 
people into trouble.  If you file off all the points and dull all the edges you 
usually do end up with a very useful tool.

-----Original Message-----
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 2:05 PM
To: Allen Wirfs-Brock
Cc: Douglas Crockford; Brendan Eich; [EMAIL PROTECTED];
Subject: Re: ES3.1 Object static methods rationale document

Allen Wirfs-Brock wrote:
> In summary, not providing reflective access to an object's prototype doesn't 
> really provide any real security, it just makes some useful tasks less 
> convenient.  Reverting to barnyard analogies: the barn door is already wide 
> open and we're debating an inch wide "trench" that spans the opening.  If we 
> want to keep the horses in we need to think about how to put an iron gate 
> across that gap rather than worrying about the risks of filling in the trench.

On the other hand, providing reflective access to an object's prototype is 
harmful to compatibility because it prevents implementations from introducing 
intermediate prototypes without breaking the web.  Consider the example of 
having just Numbers and later compatibly introducing more specific subkinds of 


Es4-discuss mailing list

Reply via email to