|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-07-17
zbm2001 写道 嗯，应该是一个实时调用的getter访问，
表现上的怪异可能是有点，但如果作为arguments的属性，似乎也有不妥的地方。 现在的标准抛弃了它——这个还真不知道，csf178 能否详细点说明一下？ 如果已不是标准，再讨论这个caller的价值就不大了。 还有，如果已不是标准，有什么好的代替方法获取这个caller呢…… 比如像我在4#楼给出的示例。 我的标题都明确了不标准不兼容,纯属讨论的.所以价值问题不是基于浏览器和标准的,是基于用途的. 首先我认为,arguments这个运行期设施是很有价值的,但是把caller附在arguments.callee.caller这个位置不怎么好, 还是直接arguments.caller的好,因为arguments是运行期的,而arguments.callee.caller有二义性,可能和原属性冲突. 这一点是和csf178的观点是一致的. 不过从一些文章上看,(mozilla的) 引用 arguments.caller can no longer be used. You can use the non-standard caller property of a function object instead. See its description for details. arguments.caller property is only available within the body of a function. 关于Function:caller的说明 引用 If the function f was invoked by the top level code, the value of f.caller is null, otherwise it's the function that called f This property replaces deprecated arguments.caller. 貌似由于某种原因主动抛弃了arguments.caller这种用法.不明白. |
| 返回顶楼 | |
|
发表时间：2008-07-17
arguments是运行期的这个一点没错，但是我相信规范制定者不会看不到这点的。
丢弃它，我猜想一定是引擎实现上的某些原因导致的。 引擎需要获得一个函数运行时的arguments.caller，根据调用栈scope逐步查找，首先当然是找到创建这个arguments的函数运行时scope，然后再找到调用这个函数的上层scope，然后再查找（如果存在）上层scope的arguments.caller…… 表现为： arguments.caller.arguments.caller.arguments.caller…… 而arguments.callee.caller则表现为： arguments.callee.caller.caller.caller…… 所以我觉得arguments.caller在引擎实现上的实际过程可能就是基于后者的（不一定是脚本里的.caller）。 至于arguments.callee.caller有二义性，arguments.caller也一样啊，只不过因为arguments本身定死了是只读的而已。 按一楼这种硬编码式的修改，javascript等动态语言很多基本属性都有这种问题。 还是老话，任何事情只有更好，没有最好，希望老大们更好的指正。 |
| 返回顶楼 | |
|
发表时间：2008-07-17
zbm2001 写道 arguments是运行期的这个一点没错，但是我相信规范制定者不会看不到这点的。
丢弃它，我猜想一定是引擎实现上的某些原因导致的。 引擎需要获得一个函数运行时的arguments.caller，根据调用栈scope逐步查找，首先当然是找到创建这个arguments的函数运行时scope，然后再找到调用这个函数的上层scope，然后再查找（如果存在）上层scope的arguments.caller…… 表现为： arguments.caller.arguments.caller.arguments.caller…… 而arguments.callee.caller则表现为： arguments.callee.caller.caller.caller…… 所以我觉得arguments.caller在引擎实现上的实际过程可能就是基于后者的（不一定是脚本里的.caller）。 至于arguments.callee.caller有二义性，arguments.caller也一样啊，只不过因为arguments本身定死了是只读的而已。 按一楼这种硬编码式的修改，javascript等动态语言很多基本属性都有这种问题。 还是老话，任何事情只有更好，没有最好，希望老大们更好的指正。 其实标准里面没有caller 我说arguments.caller比较合适的唯一理由是每次arguments构造对应着一个function call caller没法从scope chain上找出来 是个麻烦的事情 |
| 返回顶楼 | |
|
发表时间：2008-07-17
为什么要知道每个函数对象execution context对应的调用函数,如果非得想知道,大可以把函数引用传近来,caller意义不大
|
| 返回顶楼 | |
|
发表时间：2008-07-25
Function.caller现在的定义显然有一个问题，就是无法支持一个函数在调用链上出现两次。而且在function实例上不可能支持。除非定义在一个调用时的变量上，类似arguments（但是这样为什么不直接作为参数传入呢）。
而且总的来说caller似乎也没什么特别用途。 |
| 返回顶楼 | |
|
发表时间：2008-07-25
什么叫“一个函数在调用链上出现两次”？
“但是这样为什么不直接作为参数传入呢”，你指的是类似W3C事件函数的事件对象（e）传参方式？ |
| 返回顶楼 | |
|
发表时间：2008-07-26
zbm2001 写道 什么叫“一个函数在调用链上出现两次”？
“但是这样为什么不直接作为参数传入呢”，你指的是类似W3C事件函数的事件对象（e）传参方式？ 假设调用链是： a -> b -> c -> c -> ... 其中 c 进行了递归调用。 则 c.caller 就是 c，你无法回溯到b了。 除非caller不是在function实例上，而是一个函数局部变量类似arguments。但是在这种情况下，实际相当于函数增加了一个参数（即调用者）。 所以在实践中caller是几乎没有意义的。 |
| 返回顶楼 | |
