Why deprecate function caller access?
António Marques
Sorry if this's been discussed before, I couldn't find it.
As well you know, the ECMAScript standard doesn't include any way to
access a function's caller. This has been available on Mozilla and IE as
a 'caller' property of function objects, and it seems Konqueror/Safari
now have it too. Opera doesn't. And what bothers me is that it is marked
as 'deprecated'.
I've seen people I respect swear by their lives that it is *good* to
have it deprecated. 'Because there are better ways of doing what you
want'. I can't understand this. They keep repeating that even after one
says that what one wants is *precisely* to get a reference to the
caller. I can perfectly well understand that power can be mishandled,
but that is no reason to take power away when there is no other
alternative. If the fear of having javascript's features misused could
be invoked to remove features, one would end up pretty fast with no
javascript at all. Almost anything can be misused, and I see better
candidates for exclusion.
Admittedly the mechanism could be improved - beginning with having a
special variable which would refer to the current function itself and
from which all context information could be derived, and if a special
variable doesn't sound good, then by all means a member of the Function
object - something like Function.current, or Function.getCurrent() -
would be welcome. But what is not welcome at all is the menace of
removal of a basic feature of the language with no alternative at all.
Sorry, but just to say that 'caller isn't needed' is the same as calling
the other person stupid. Of course there might be some uses of 'caller'
which could be solved in a different, better way. Not all of them,
though, and what is gained by removing it other than ego-rubbing?
I should point out that 'goto' (as if it were a comparable case!) has
alternatives. There is nothing you can do with it that you can't do
without. Not so here.
Could anyone explain this to me?
Cheers,
Antonio
--
Posted via a free Usenet account from http://www.teranews.com
Thomas 'PointedEars' Lahn
> I've seen people I respect swear by their lives that it is *good* to have
ISTM that the statement becomes more understandable when considering the
context in which it was given, that you have not told about. IOW: *What*
is it exactly that you want?
> They keep repeating that even after one says that what one wants is
> *precisely* to get a reference to the caller.
But *why* do you want that?
> I can perfectly well understand that power can be mishandled, but that is
> no reason to take power away when there is no other alternative.
I wonder what you think the power would be. With a caller property or a
reference passed as an argument, you will only get a reference to a Function
object (or `null'). You cannot know, without much effort in manually
bookkeeping object references, what that Function object is a method of,
nor, to make matters even more complicated, as the method of which object
it was called.
> If the fear of having javascript's features misused could be invoked to
> remove features, one would end up pretty fast with no javascript at all.
I don't think possible misuse was the reasoning for the decision, but rather
deemed uselessness and observed missing universal implementation, as
demonstrated by your stating that Opera's script engine lacking it. It
would be reasonable to exclude such a feature from the Specification, as
section 2 of the Specification allows implementations to support properties
that were not specified (among other things). The decision of the
implementors to deprecate that property is an entirely different matter --
why don't you ask *them* about it?
> Admittedly the mechanism could be improved - beginning with having a
> special variable which would refer to the current function itself
You mean the standardized arguments.callee property?
> and from which all context information could be derived,
It would seem that this information is somehow exposed internally, otherwise
Venkman and Firebug could not provide it.
> [...] Sorry, but just to say that 'caller isn't needed' is the same as
> calling the other person stupid. [rant]
Name at least one example where you deem a caller property to be required
and we can discuss it then. Anything else is just a waste of time.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
VK
> Hi,
>
> Sorry if this's been discussed before, I couldn't find it.
> As well you know, the ECMAScript standard doesn't include any way to
> access a function's caller. This has been available on Mozilla and IE as
> a 'caller' property of function objects, and it seems Konqueror/Safari
> now have it too. Opera doesn't. And what bothers me is that it is marked
> as 'deprecated'.
There are caller[1] (of function), caller[2] (of current instance) and
__caller__ (Netscape proprietary for caller[2]
caller[2] and __caller__ are potentially dangerous as opening a way to
get into execution stack within default security. This way they were
either patched for functionality decrease or removed. caller[1] is
secure but just went under the same security campaign by mistake.
Following is a Brendan Eich comment on Mozilla 0.9 (2001-01-10):
"All traces of a caller property were removed a while ago,
to follow ECMA-262 and to avoid any chance of a security exploit.
The removal seems to me to have been overzealous, because it axed
the caller property of function objects *and* the
much-more-exploitable caller (or __caller__) property of
activation objects.
"Confirming, we should consider restoring the caller property
of function objects for old time's sake (JScript imitated it
faithfully in cloning JS1.1, where it originated)."
See also in depth discussion on the topic at
"Recursive functions and arguments.callee.caller"
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/87fd9c1a17c21ca5
Csaba Gabor
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/87fd9c1a17c21ca5/
Also, I logged a bug report at:
https://bugzilla.mozilla.org/show_bug.cgi?id=332104
Csaba Gabor from Vienna
John G Harris
Marques wrote:
>Hi,
>
>Sorry if this's been discussed before, I couldn't find it.
>As well you know, the ECMAScript standard doesn't include any way to
>access a function's caller. This has been available on Mozilla and IE as
>a 'caller' property of function objects, and it seems Konqueror/Safari
>now have it too. Opera doesn't. And what bothers me is that it is marked
>as 'deprecated'.
This problem appeared in the early days of computing. Sometimes the code
in a function needs to know something. The solution was ingenious. The
caller supplies 'arguments' that tell the function what it needs to
know. Clever, eh?
John
--
John Harris
António Marques
>> Sorry if this's been discussed before, I couldn't find it. As well
>> you know, the ECMAScript standard doesn't include any way to access
>> a function's caller. This has been available on Mozilla and IE as
>> a 'caller' property of function objects, and it seems
>> Konqueror/Safari now have it too. Opera doesn't. And what bothers
>> me is that it is marked as 'deprecated'.
> <snip>
>
> This problem appeared in the early days of computing. Sometimes the
> code in a function needs to know something. The solution was
> ingenious. The caller supplies 'arguments' that tell the function
> what it needs to know. Clever, eh?
My fault, I apologise. I forgot to ask for intelligent opinions only.
António Marques
> You may find the following thread on caller, callee interesting:
>
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/87fd9c1a17c21ca5/
>
> Also, I logged a bug report at:
> https://bugzilla.mozilla.org/show_bug.cgi?id=332104
Well, they do say ->
> The good news is that ECMA TG1 is busy working on Edition 4, and part
> of that (still not a done deal) is stack reflection.
-> which is quite interesting. Does anyone have any more info on that?
Thanks,
António Marques
>> As well you know, the ECMAScript standard doesn't include any way
>> to access a function's caller. This has been available on Mozilla
>> and IE as a 'caller' property of function objects, and it seems
>> Konqueror/Safari now have it too. Opera doesn't. And what bothers
>> me is that it is marked as 'deprecated'.
>
> There are caller[1] (of function), caller[2] (of current instance)
> and __caller__ (Netscape proprietary for caller[2]
>
> caller[2] and __caller__ are potentially dangerous as opening a way
> to get into execution stack within default security. This way they
> were either patched for functionality decrease or removed.
Even if I was refering to caller[1] (''caller' property of function
objects'), I'd be interested in knowing what was so dangerous about
granting access to the activation object in itself anyway that the whole
object had to be locked out.
> caller[1] is secure but just went under the same security campaign by
> mistake.
>
> Following is a Brendan Eich comment on Mozilla 0.9 (2001-01-10):
>
> "All traces of a caller property were removed a while ago, to follow
> ECMA-262 and to avoid any chance of a security exploit. The removal
> seems to me to have been overzealous, because it axed the caller
> property of function objects *and* the much-more-exploitable caller
> (or __caller__) property of activation objects.
>
> "Confirming, we should consider restoring the caller property of
> function objects for old time's sake (JScript imitated it faithfully
> in cloning JS1.1, where it originated)."
I did endure Netscape 4.72 as my browser since it appeared until Mozilla
reached 1.2 - I think this may have been fixed by then, I don't recall
having had any issues. Certainly Gecko 1.8 has a Function.prototype.caller.
> See also in depth discussion on the topic at "Recursive functions and
> arguments.callee.caller"
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...
Hey, thanks.
António Marques
>> I've seen people I respect swear by their lives that it is *good*
>> to have it [the caller property] deprecated. 'Because there are
>> better ways of doing what you want'. I can't understand this.
>
> ISTM that the statement becomes more understandable when considering
> the context in which it was given, that you have not told about. IOW:
> *What* is it exactly that you want?
Sorry, I thought it was obvious: it's a general remark. 'Because there
are better ways of doing what you want, whatever it is that you want'.
'I want to know from which code path is this being called'.
>> They keep repeating that even after one says that what one wants is
>> *precisely* to get a reference to the caller.
>
> But *why* do you want that?
Make it an end in itself, if you want.
>> I can perfectly well understand that power can be mishandled, but
>> that is no reason to take power away when there is no other
>> alternative.
>
> I wonder what you think the power would be. With a caller property
> or a reference passed as an argument, you will only get a reference
> to a Function object (or `null'). You cannot know, without much
> effort in manually bookkeeping object references, what that Function
> object is a method of, nor, to make matters even more complicated, as
> the method of which object it was called.
I wonder the same - what risk can it be? But it *can* give you the
source of the caller, which *may* help you determine which function is
the caller, among a number of possibilities.
>> If the fear of having javascript's features misused could be
>> invoked to remove features, one would end up pretty fast with no
>> javascript at all.
>
> I don't think possible misuse was the reasoning for the decision, but
> rather deemed uselessness
I'd have to take that as a reason for not implementing it in the first
place, but not for deprecation. And I've never seen a feature removed
from any language unless an alternative were available, and certainly
real or perceived usefulness is a barren point - it is either used or
not. Could you give any counter-examples?
> and observed missing universal implementation, as demonstrated by
> your stating that Opera's script engine lacking it. It would be
> reasonable to exclude such a feature from the Specification, as
> section 2 of the Specification allows implementations to support
> properties that were not specified (among other things). The
> decision of the implementors to deprecate that property is an
> entirely different matter -- why don't you ask *them* about it?
I thought it would be interesting to have the opinion of the Wise People
of c.l.j.
Of course, not everyone here needs to be interested in ECMAScript design
issues.
>> Admittedly the mechanism could be improved - beginning with having
>> a special variable which would refer to the current function itself
>>
>
> You mean the standardized arguments.callee property?
No, I mean something *like* it. Why should 'callee' be a property of the
arguments? 'arguments' should be a property of the callee.
>> and from which all context information could be derived,
>
> It would seem that this information is somehow exposed internally,
> otherwise Venkman and Firebug could not provide it.
Certainly, but this discussion is about javascript, not xul.
>> [...] Sorry, but just to say that 'caller isn't needed' is the same
>> as calling the other person stupid.
>
> Name at least one example where you deem a caller property to be
> required and we can discuss it then. Anything else is just a waste
> of time.
'I want to know who the caller is. For the sake of it'.
I shouldn't have to give you an example, since this is a matter of
principle and what I asked for was a general opinion - if you think
*that* is a waste of time, then possibly I won't be able to exact a
useful opinion from you anyway.
But suppose you have library function 'a', which can be called from a
zillion places. You find out it is being called inapproprately
somewhere, but where? Is it function b? c? d? ...? z? I suppose you'll
tell me to change the 489 places where function 'a' is invoked just to
add arguments.callee to the call. Or maybe I should use a debugger -
though in this case a debugger is hardly a good option, since I don't
want to stop execution unconditionally - or I may not have a debugger
available for that browser. Logging the caller (or any recognisable
property of it) to the screen is the natural and correct way to go on
about solving this problem.
> [rant]
That which you classify as 'rant' was actually ->
'Of course there might be some uses of 'caller' which could be solved in
a different, better way. Not all of them, though, and what is gained by
removing it other than ego-rubbing? I should point out that 'goto' (as
if it were a comparable case!) has alternatives. There is nothing you
can do with it that you can't do without. Not so here.'
-> all of which was just illustration of the issue at hand, even if the
last clause of the second sentence is somewhat inflammatory. This is
context, it's trying to explain to you where I'm coming from. Skipping
such information as a 'rant' hampers your ability to engage a meaningful
discussion.
Summing it all up, I see *nothing at all* gained in removing the
'caller' property of function objects. Even if one were to grant that
the property was useless - which it isn't - removing it would result in
zero gain. An action which results in - according to whom you ask -
either zero gain or some loss, shuld not be undertaken. This is
basically why saying that 'uselessness' is a rationale for removal is
inconsiderate (inter alia, a 'waste of time').
Now, someone may argue that providing a 'caller' property is expensive,
harmful, risky, difficult, superseeded, whatever. Those are sensible
arguments. Please go ahead, I'd be interested in listenning. Maybe
javascript benefits in some way from removing it? I honestly don't know.
If someone's got an opinion, please give it.
Thank you,
John G Harris
And you got them.
You are asking the compiler to supply information that is needed only in
special circumstances, but not to supply information that might be
needed in other special circumstances.
You shouldn't be surprised if your special circumstances aren't seen as
important by the browser designers and other circumstances are.
John
--
John Harris