[[Call]] vs. [[Construct]] using symbols
herby at mailbox.sk
Mon Oct 8 01:07:31 PDT 2012
Herby Vojčík wrote:
> Dmitry Soshnikov wrote:
>> FWIW, we'd better stick with some reduced number of methods for
>> 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,
s/pre se/per se/
> 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).
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss