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

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Sun Oct 7 16:27:20 PDT 2012


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; IIRC, the last time we were talking about unstratified traps, it was said like "no one needs these Pythonish __names__, we need proxies". Although, I don't see nothing too bad if the traps will be defined directly on objects, especially if with some @"private" semantics which cannot be just read as a simple property).
 
What I'm saying -- better not to create too many the same entities for similar purposes. If we'll have some unstratified private hooks, I can predict no one will need proxies or Object.observe.

Dmitry


On Oct 7, 2012, at 3:02 PM, Kevin Smith wrote:

> 
> 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 sometimes users legitimately want to call [[Construct]] to initialize an existing object, and there needs to be a way to do that.
> 
> Kevin
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121007/0d26ee89/attachment.html>


More information about the es-discuss mailing list