Re: [[Call]] vs. [[Construct]] using symbols

2012-10-07 Thread Herby Vojčík
Brendan Eich wrote: Before we add more unstratified traps, I'd like Tom and Mark to comment. They've thought a lot about invariants to preserve even with proxies in the picture, and also for non-proxies. And they have a use-case to test against: SES. Herby Vojčík wrote: But this has some

Re: [[Call]] vs. [[Construct]] using symbols

2012-10-07 Thread Rick Waldron
On Sun, Oct 7, 2012 at 5:10 AM, Herby Vojčík he...@mailbox.sk wrote: Brendan Eich wrote: Before we add more unstratified traps, I'd like Tom and Mark to comment. They've thought a lot about invariants to preserve even with proxies in the picture, and also for non-proxies. And they have a

Re: [[Call]] vs. [[Construct]] using symbols

2012-10-07 Thread Kevin Smith
It addresses a common pattern today, that looks like: function Led( opts ) { if ( !(this instanceof Led) ) { return new Led( opts ); } // ... } Yes - I explored this idea back when we were discussing classes several months ago. The thing that you have to consider is that

Re: State of discussion - module / Import syntax

2012-10-07 Thread Shijun He
On Tue, Sep 25, 2012 at 1:02 AM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: I find this interesting as well, because I've been thinking of creating Yet Another(TM) module loader, which would be a standalone polyfill for Harmony modules. I just wrote one:

Re: [[Call]] vs. [[Construct]] using symbols

2012-10-07 Thread Dmitry Soshnikov
FWIW, we'd better stick with some reduced number of methods for meta-traps. As it turns out, we already have several different techniques which solve nearly the same problems: - Proxies, - Object.observe - Unstratified proposals like this one (which BTW, have been already discussed many times;