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

Herby Vojčík herby at mailbox.sk
Mon Oct 8 01:04:57 PDT 2012



Dmitry Soshnikov wrote:
> 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.

I still have the feeling proxies are too big bullet for this. I see the 
place of proxies in meta-programming pre se, simulating whole protocals, 
filling missing properties not envision before etc.

To use a proxy to do such a natural thing as splitting [[Call]] and 
[[Construct]] seems to be a bit of misuse. For me.

But if there is a "no __init__" movement there, ok. I just pointed to 
that fact of @iterator, and honestly I think @call and @construct are on 
the same level - enabling declaration of behaviour for basic, 
not-so-meta, language constructs (be it for-of or new/super).

> Dmitry

Herby


More information about the es-discuss mailing list