On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote:
> I think this example is contrived, but illustrates the point that JavaScript
> is very dynamic, and sometimes in the building process an object can be out
> of sync from its constructor. My expectations when I see this would be that
> my results would be a constructor function that can be used to produce a new
> version of the UnaryExpression, calling its constructor code. The best way I
> can think of to do this would be:
>
> function classify(obj){
> let sub = obj <| {
> constructor(...args){
> super.constructor(...args);
> }
> }
> sub.constructor.prototype = sub;
> return sub.constructor;
> }
>
> The key is that the UnaryExpression is not modified, and it should still work
> even if a constructor is missing. If the UnaryExpression is unobservable and
> had an own constructor property I would expect that the <| portion can be
> skipped, and the constructor would just be modified directly to point back at
> the enclosing object literal.
Optimizations must be unobservable except by benchmarking or other kinds of
profiling. But if I'm following you correctly, even if the UnaryExpression
operand is a fresh object literal with an own 'constructor' property, the
result of skipping <| differs observably from the case where the operand is not
fresh:
class {p: "I'm own"}
vs.
class compute_object_with_own_p();
where compute_object_with_own_p returns an object {p: "I'm own too"}.
In the latter case, returning a new object whose [[Prototype]] references the
non-fresh {p: "I'm own too"} object makes an observable difference in where 'p'
lives.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
