The class operator: a bridge between object and function exemplers

[Russell Leggett]

On Tue, Nov 15, 2011 at 1:01 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Nov 15, 2011, at 9:56 AM, Brendan Eich wrote:
>
> > 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"}
>
> Oops, that should have been:
>
> class {p: "I'm own", constructor(){}}
>
> of course.
>
> /be
>

Yes, of course you're right about that. There was something in the back of
my brain saying there might be a problem with that optimization, but I had
hoped it could be done, because that is probably the most common case.  I
suppose you could say that it isn't an optimization, but simply part of the
semantics. Not sure if that would be confusing or just seem like the right
behavior.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111115/87e8be57/attachment-0001.html>