`callee` could be spec'd similar to `super` and transpiled or resolved statically instead of dynamically, but `callee.caller` or in general the function `caller` raised many security concerns, giving you the ability to reach objects you probably shouldn't have.
These two were different beasts, but `callee` for numerous reasons, and specially for anonymous and non referenced Object methods syntax, is really leaving a hole in the language, IMO Best Regards On Thu, Feb 26, 2015 at 5:41 PM, Felipe Nascimento de Moura < [email protected]> wrote: > that's true! > I miss that too! > We are working on a framework for the company here, and sometimes, getting > the callee would be really useful, and we simply can't!!! > Removing the arguments.caller/calee could make more sense if, like other > features, had been replaced by another syntax. > > What was the main reason why caller/calee were removed? > > Cheers. > > > On Thu, Feb 26, 2015 at 2:09 PM, Andrea Giammarchi < > [email protected]> wrote: > >> I miss you `arguments.callee`, specially in this "fat arrows era" where >> most of the time developers don't even care about removing listeners. >> >> Apologies for the laud thought and Best Regards >> >> On Thu, Feb 26, 2015 at 4:32 PM, Allen Wirfs-Brock <[email protected] >> > wrote: >> >>> >>> On Feb 26, 2015, at 4:10 AM, Leon Arnott wrote: >>> >>> The twitter thread starts here: >>> https://twitter.com/getify/status/570614952605560838 and basically >>> boils down to the observation that this: >>> ``` >>> ({ f() { return f; }}.f()) /* ReferenceError (probably) */ >>> ``` >>> is not semantically identical to this: >>> ``` >>> ({ f: function f() { return f; } }.f()) /* function f() */ >>> ``` >>> That is, concise methods cannot seamlessly recursively call or reference >>> themselves. (Personally, I feel like concise methods *should* be a binding >>> within themselves in a manner identical to named function expressions, but >>> if this has been discussed before and discarded then I understand.) >>> >>> You may notice that both of the methods above have the same name, "f", >>> in spite of one lacking the lexical binding. Formerly, named functions >>> always (barring internal var statements etc.) had lexical bindings to >>> themselves, and the whole ES6 function name inference dealie breaks this >>> correlation. I don't think this is really an important issue, though - >>> assuming that a `.name` property equated to a binding was not a safe >>> assumption (especially since IE never implemented `.name` but did support >>> the binding). >>> >>> >>> Note that property names are restricted to being valid identifiers. >>> Note of the following concise methods could possibly use their property >>> name as a lexical binding: >>> >>> let o = { >>> 42() {}, >>> " this is not an identifier"() {}, >>> ""() {}, >>> if() {}, >>> [Symbol.iterate]() {} >>> }; >>> >>> We may have a universal way for functions to self reference themselves i >>> post ES6. >>> >>> allen >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > *Felipe N. Moura* > Senior Web Developer > > Website: http://felipenmoura.org > Twitter: @felipenmoura <http://twitter.com/felipenmoura> > LinkedIn: http://goo.gl/qGmq > > Meet some of my projects: > BrazilJS Conference <http://braziljs.com.br/> | BrazilJS Foundation > <http://braziljs.org> | Power Polygon > <http://github.com/braziljs/power-polygon> | TheWebMind > <http://thewebmind.org/> | PHPDevBar > <https://addons.mozilla.org/pt-BR/firefox/addon/php-developer-toolbar/> > --------------------------------- > LinuxUser #508332 > *Changing the world* is the least I expect from myself! >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
