2010/4/16, Brendan Eich <[email protected]>:
> On Apr 16, 2010, at 7:18 AM, Asen Bozhilov wrote:
Special thanks for your response!
>> Especially when I want to change only [[Prototype]] and keep values of
>> other internal properties and methods for that object.
> I write this having designed and implemented settable __proto__ over
> 12 years ago. At the time, unstratified metaprogramming APIs were
> popular; if it was good enough for Python, why not for JS. But the
> lack of stratification is a problem (consider JSON data with a key
> "__proto__").
> And worse, the mutability means implementations must
> check for cyclic prototype chains in order to avoid ilooping.
>
> Mutable __proto__ also makes optimization harder, or simply defeats
> optimizations at the price of some complexity in the engine.
I agree with your attentions. For example, I ever wonder how you treat
identifier with name `__proto__`. Perhaps that depend on
implementation of Activation/Variable object.
(function () {
var __proto__ = {x : true};
print(x);
})();
If VO is implemented as native object, that code will pollute Scope
Chain and `x' will be resolve from VO[[Prototype]] during identifier
resolution.
>From your attentions, they can use another approach. For example:
Object.prototype.setPrototype = function(proto) {
};
Of course that should be check for cycling chain, which can be
performance inefficient.
Another approach is "proxy" object between object and its
[[Prototype]]. For example:
Object.prototype.proxy = function(properties) {
var nativeObject = properties.clone();
nativeObject.__proto__ = this.__proto__;
this.__proto__ = nativeObject;
return nativeObject;
};
That will be solve cycling chain checking, and will allow programmers
for more intelligent extend of built-in objects. Of course that is
only example, but is in the nature of ES.
> Finally, mutating __proto__ on an existing object may break non-
> generic methods in the new prototype object, which cannot possibly
> work on the receiver (direct) object whose __proto__ is being set.
> This is simply bad practice, a form of intentional type confusion, in
> general.
If programmer know what he does with the power which you provide, he
never shadow/overwrite non-generic methods.
>> And I have a question. Why ES5 give control on values of internal
>> attributes? What will improve that? "Save" augmentation of built-in?
>
> (You probably mean "Safe" here.)
Yes, apologize for my English mistakes.
> All of these, but mostly to enable higher-integrity abstractions,
> including ones that mimic the built-in objects (including the DOM --
> more generally, all the notorious "host objects"; see also
> http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
> .
>
> We do not want the built-in objects to have all the power, including
> to make properties non-enumerable and non-configurable but writable
> (more on const below). The JS authors should have this power too, so
> the committee is not a bottleneck for innovation where such attribute
> control is necessary for integrity, emulation, or some other valid
> reason.
The most JS authors use these features for patch their design. And
interface which manipulate internal attributes looks like memory
inefficient. For each defined property I should create native object.
Instead of that they can think about more simple interface which
manipulate internal attributes. For example object initialiser can
improve that:
const DONT_DELETE = 0x4,
DONT_ENUM = 0x2,
READ_ONLY = 0x1;
var obj = {
property : value : DONT_DELETE | DONT_ENUM,
property2 : value : READ_ONLY | DONT_DELETE
};
Best regards!
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
