I didn't specifically respond to that thread because I wasn't aware of it.  I 
had intended to mention __proto__ as a precedent but it slipped through the 

It's true that __proto__ or getPrototypeOf breaks an object's encapsulation 
barrier and reveals implementation details that perhaps were intended to be 
hidden.  The same could be said about the proposed getProperty function which, 
among other things,  gives an observer access to the functions that implement a 
getter/setter property. In general, that's the nature of reflection. Overall, I 
think that this is a situation that is inherent in our current generation of 
dynamic languages. They tend to depend upon the use of idioms that require 
penetration of the encapsulation barrier.

Some of the concerns expressed in that thread are address by other aspects of 
the static Object methods proposal.  For example, the integrity of prototype 
objects can be protected by sealing them in whole or in part to prevent 
tampering. Also note, that while we support inspection of the prototype value, 
we don't support modification of it.

As Doug implies below, one reason for making these operations "static methods" 
was to make it easier to control access to them.  It you are creating some sort 
of sandbox, you may not want to make them available within it.  That could be 
taken as a argument in favor of hanging them off of a dedicated global Meta 
object rather than off of Object.  It may be slightly easier to wholesale 
restrict access to Meta than it would be to restrict access to just these 
methods while still providing access to the Object constructor.

Another already available technique for obtaining the same information in many 
situations that wasn't mentioned in the thread is to use 
Object.prototype.isPropertyOf as a probe to discover the prototypes of objects. 
It isn't something that you would want to do in production code but I don't 
think that anyone who was trying to crack an application would hesitate from 

Arguably, some of the need for direct prototype access is alleviated by 
providing the clone method.  However, there are still plenty of other 
situations where it is useful.

I don't agree with Lars' contention that __proto__ and function.caller present 
the same kind of problem. True, they both break abstraction barriers, but 
different  barriers.  __proto__ breaks the object implementation abstraction 
layer.  Function.caller breaks the call stack abstraction. Crossing the object 
implementation boundary is generally required for defining object abstractions 
in this language and __proto__ only reveals information that in most cases is 
already available through other, less direct, means. In contrast, 
function.caller reveals information about the call stack that is not normally 
reified in this language or generally needed (those who consider continuations 
the ultimate programming abstraction may disagree).

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.


-----Original Message-----
From: Douglas Crockford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 5:39 AM
To: Brendan Eich
Cc: Allen Wirfs-Brock; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document

Brendan Eich wrote:
> * No rationale responding to the thread containing this message:
> https://mail.mozilla.org/pipermail/es4-discuss/2007-September/001114.html
> that questions the wisdom of getPrototypeOf. The other rationales are
> helpful, the lack of one responding to this public thread questioning
> essentially the same design element is a lack -- what do you think?

The motivation for these methods is to allow Ajax libraries and the Caja runtime
to harden the environment. Such a library can use and them remove these methods,
disallowing access by guest code.

> * Did you consider prototype's Object.extend method:
> Object.extend = function(destination, source) {
>   for (var property in source)
>     destination[property] = source[property];
>   return destination;
> };

Yes we did.

Es4-discuss mailing list

Reply via email to