Why deprecate function caller access?

A

António Marques

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'.

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
 
T

Thomas 'PointedEars' Lahn

António Marques said:
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?
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
 
V

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
 
J

John G Harris

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'.
<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?

John
 
A

António Marques

VK said:
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.
 
A

António Marques

Csaba said:

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,
Antonio
 
A

António Marques

Thomas 'PointedEars' Lahn wrote:

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'.
But *why* do you want that?

Make it an end in itself, if you want.
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.
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.
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.
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.

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,
Antonio
 
A

António Marques

John said:
<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.
 
J

John G Harris

My fault, I apologise. I forgot to ask for intelligent opinions only.

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,981
Messages
2,570,188
Members
46,731
Latest member
MarcyGipso

Latest Threads

Top