a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Mar 8 13:32:46 PST 2013


I'd love to see caller dead **only** after a well engineered solution take
its place and is widely adopted, which is the reason I've asked about this
future solution I've never seen discussed here.

So, the question is: is there any plan to discuss, to put in agenda, to
bring, a "caller" alternative to ES.next ?

Thanks


On Fri, Mar 8, 2013 at 1:25 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> The way caller is a single attribute of the function object arguably makes
> it useless for authoring reusable code: it breaks in the presence of
> reentrance, and requires you to keep an accessible reference to every
> function that might want to know its caller, exposing you to leaks and
> making closures harder to use in such scenarios.
>
> The problems it's intended to solve are important, but it's a really poor
> solution to them. I'd love to see caller dead for good and a well
> engineered solution take its place.
> -kg (mobile)
>
> Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>>
>> I wonder if there's any discussion about it for ES.next
>>
>> while callee has always been kinda pointless in my opinion, caller
>> property is not replaceable at all.
>>
>> Internally, for scope lookup reasons, the caller is always passed
>> somehow, except, I guess, where there's no caller access and the function
>> is optimized thanks to absent outer scope look up.
>>
>> Why caller? Because there's no other way to understand which method
>> invoked a getter, as the very most basic example.
>>
>> var obj = Object.defineProperty({}, "caller", {get: function get(){
>>   return get.caller;
>> }});
>>
>> obj.method = function method() {
>>   alert(this.caller === method);
>> };
>>
>> This opens doors to debuggers (introspection) and APIs magic quite a lot.
>>
>> 2 extra points:
>>   1) I have not even mentioned arguments, which is not mandatory for
>> caller
>>   2) I haven't used callee and I don't care about callee
>>
>> Last, but not least, the more I think about the inability to switch
>> "strict mode" in the wild the more patterns from ES3 injected into ES.next
>> come up in my mind.
>>
>> Thanks for any sort of response
>>
>> ------------------------------
>>
>> 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/20130308/9456be9d/attachment.html>


More information about the es-discuss mailing list