By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,353 Members | 1,555 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,353 IT Pros & Developers. It's quick & easy.

What's wrong with arguments.callee ?

P: n/a
Why is it listed here :

http://www.crockford.com/javascript/recommend.html

under "deprecation" ?

Without it, how is an anonymous function() going to call itself
(recursively) ?

I use to write timers like this :

setTimeout( function () {
(...)
setTimeout( arguments.callee, ms );
}, ms );

How am I suppossed to do that without arguments.callee ?

Thanks,
--
Jorge.
Sep 14 '08 #1
Share this Question
Share on Google+
34 Replies


P: n/a
Jorge <jo***@jorgechamorro.comwrites:
Why is it listed here :

http://www.crockford.com/javascript/recommend.html

under "deprecation" ?
I really don't know.
Without it, how is an anonymous function() going to call itself
(recursively) ?
Look up the Y combinator.

http://en.wikipedia.org/wiki/Y_combinator
http://javascript.crockford.com/little.html

function Y(le) {
return function (f) {
return f(f);
}(function (f) {
return le(function (x) {
return f(f)(x);
});
});
}

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Sep 14 '08 #2

P: n/a
Joost Diepenmaat wrote:
Jorge <jo***@jorgechamorro.comwrites:
>Why is it listed here :

http://www.crockford.com/javascript/recommend.html

under "deprecation" ?

I really don't know.
>Without it, how is an anonymous function() going to call itself
(recursively) ?

Look up the Y combinator.

http://en.wikipedia.org/wiki/Y_combinator
http://javascript.crockford.com/little.html

function Y(le) {
return function (f) {
return f(f);
}(function (f) {
return le(function (x) {
return f(f)(x);
});
});
}
After reading the links and trying to understand the
above function a question arose: why not
use a non-anonymous function instead of anonymous?


Sep 14 '08 #3

P: n/a
On Sep 14, 12:04*pm, "optimistx" <optimistxPoi...@poistahotmail.com>
wrote:
>
After reading the links and trying to understand the
above function
And did you get it ? (I still don't).
a *question arose: why not
use a non-anonymous function instead of anonymous?
Yes, that's a solution, one that needlessly wastes a symbol name
(functionName), and furthermore, arguments.callee is 100% unambiguous,
while functionName might not.

Anyhow, just out of curiosity, why do they want to get rid of it ?

--
Jorge.
Sep 14 '08 #4

P: n/a
On Sep 14, 12:04*pm, "optimistx" <optimistxPoi...@poistahotmail.com>
wrote:
>
After reading the links and trying to understand the
above function *a *question arose: why not
use a non-anonymous function instead of anonymous?
Guess what ?
See:
>var foo = function bar(x) { ... bar(y) ... }
works fine, so long as bar isn't shadowed in the function body.
>Does not quite work on the current web - JScript binds the "bar" name
in the containing scope, not the contained scope as ES3 specs it. That
means the inner name isn't really usable for recursion unless the
script author actually makes sure it stays unmodified in the
containing scope."
LOL: "Seems to not have been fixed in ie8b2 / JScript5.8."

https://mail.mozilla.org/pipermail/e...er/007453.html

--
Jorge.
Sep 14 '08 #5

P: n/a
Jorge <jo***@jorgechamorro.comwrites:
Why is it listed here :

http://www.crockford.com/javascript/recommend.html

under "deprecation" ?

Without it, how is an anonymous function() going to call itself
(recursively) ?
If it's going to call itself recursively, it shouldn't be anonymous.
I use to write timers like this :

setTimeout( function () {
(...)
setTimeout( arguments.callee, ms );
}, ms );
setTimeout(function rec() {
(...)
setTimeout(rec, ms);
}, ms);

(or use setInterval)
/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Sep 14 '08 #6

P: n/a
On Sep 14, 9:46*pm, Lasse Reichstein Nielsen <lrn.unr...@gmail.com>
wrote:
>
If it's going to call itself recursively, it shouldn't be anonymous.
"it shouldn't be anonymous" because... ?

--
Jorge.
Sep 14 '08 #7

P: n/a
On Sep 14, 5:18*am, Jorge <jo...@jorgechamorro.comwrote:
Why is it listed here :

http://www.crockford.com/javascript/recommend.html

under "deprecation" ?

Actually, I don't really understand the reason for any of the listed
language elements being deprecated. I've heard many good arguments for
all of them being used sparingly but in my job I have to occasionally
use Javascript hosted by Windows Scripting Host. It would be very
difficult to get along without "new" and "eval" in this environment
(just think about the lack of a <scripttag). I think, perhaps,
Crockford's recommendations are coming from a browser centric place
which is fine but shouldn't ECMA script be host independent?

Bob
Sep 15 '08 #8

P: n/a
On Sep 15, 2:51 pm, beegee wrote:
On Sep 14, 5:18 am, Jorge wrote:
>Why is it listed here :
>>http://www.crockford.com/javascript/recommend.html
>under "deprecation" ?

Actually, I don't really understand the reason for any of the
listed language elements being deprecated. I've heard many good
arguments for all of them being used sparingly but in my job I
have to occasionally use Javascript hosted by Windows Scripting
Host. It would be very difficult to get along without "new" and
"eval" in this environment
The page referenced above does not suggest that you should have to get
along without using "new", but what is so necessary about "eval"? (If
it is for referencing global functions using string names then you
don't need eval for that.)
(just think about the lack of a <scripttag).
What does that have to do with anything?
I think, perhaps, Crockford's recommendations are coming from a
browser centric place which is fine but shouldn't ECMA script
be host independent?
Browser scripting has never been Douglas Crockford's expertise (he is
a language expert), and on the whole the ECMA committee working on
ECMAScript revisions seems very lacking in browser centric expertise/
experience (Brendan Eich thinks the authors of dojo qualify as that).
Sep 15 '08 #9

P: n/a
Jorge wrote:
On Sep 14, 12:04 pm, "optimistx" <optimistxPoi...@poistahotmail.com>
wrote:
>>
After reading the links and trying to understand the
above function

And did you get it ? (I still don't).
>a question arose: why not
use a non-anonymous function instead of anonymous?

Yes, that's a solution, one that needlessly wastes a symbol name
(functionName), and furthermore, arguments.callee is 100% unambiguous,
while functionName might not.
....
I did not get it, after 2 minutes of staring. If I were a boss of a group
of programmers, and found one new program maintenance guy
struggling 15 minutes with the above code, I would be a bit angry
with the original coder. He/she
might know the language extremely well, but has obviously no idea of the
world of average programmer and the economic facts of program
developement.

If one creates one's own namespace like this:

var JORGE = {};

and uses that object to accommodate all the program variables,
functions, then the names do not collide with library variables etc :

JORGE.niceNameOfMyFunction = function () {
alert ('I try to be very nice and friendly towards everyone');
}

JORGE.goodDescriptiveName = 'property value';

JORGE.myObject = {'key1':'value1','key2':'value2'};

When working like this there is not much need to avoid
naming variables and functions clearly so that maintenance
people understand the code easily. (the maintenance person
might be the original coder after 2-3 yars wondering, what
obscure things are happening here...).
Sep 15 '08 #10

P: n/a
On 2008-09-15 16:18, Henry wrote:
On Sep 15, 2:51 pm, beegee wrote:
>[...] It would be very difficult to get along without "new" and
"eval" in this environment

The page referenced above does not suggest that you should have to get
along without using "new", but what is so necessary about "eval"? (If
it is for referencing global functions using string names then you
don't need eval for that.)
I have found eval() to be useful in two situations: efficient conversion
of a string containing JSON data to an object or array (if the source of
the data can be trusted), and evaluating the contents of <script>
elements. The latter can be necessary when an HTML fragment containing
<scriptelements is inserted using innerHTML(), and you want those
scripts to be executed.
Browser scripting has never been Douglas Crockford's expertise (he is
a language expert), and on the whole the ECMA committee working on
ECMAScript revisions seems very lacking in browser centric expertise/
experience (Brendan Eich thinks the authors of dojo qualify as that).
I have read quite a few of Crockford's articles, including his book
"javascript: The Good Parts", and while I agree with many (perhaps even
most) of his suggestions, there are others that I think are unnecessary
or even counterproductive. His aversion against the "new" operator and
his unconditional preference of function expressions vs. function
statements would be two examples.
- Conrad
Sep 15 '08 #11

P: n/a
On Sep 15, 10:18*am, Henry <rcornf...@raindrop.co.ukwrote:
On Sep 15, 2:51 pm, beegee wrote:
On Sep 14, 5:18 am, Jorge wrote:
>
The page referenced above does not suggest that you should have to get
along without using "new", but what is so necessary about "eval"? (If
it is for referencing global functions using string names then you
don't need eval for that.)
(just think about the lack of a <scripttag).

What does that have to do with anything?
Think betterer. How do you include a javascript file? Now think
about how you would do it in a non-browser hosted environment.
Honestly, if you know of a way of doing it without eval then please
let me know. You're right about "new" though. He is suggested
deprecating primitive object wrappers, not the use of "new".

On the other hand, I've read as many arguments for the use of semi-
colons as against. Seems like a personal preference.
>Browser scripting has never been Douglas Crockford's expertise (he is
a language expert)
Well, kind of, although his point of reference for last few years has
certainly been browser-side scripting (JSON and it's use in AJAX seems
to have been his major focus). In his new book, his (and others) main
argument against eval, security, is inapplicable to server side
scripting. Perhaps his recommendation to deprecate is more to spur
interest in a replacement technology but to do that, OS hosting must
be considered.

Bob

Sep 15 '08 #12

P: n/a
On 2008-09-15 22:21, beegee wrote:
You're right about "new" though. He is suggested
deprecating primitive object wrappers, not the use of "new".
He also advocates never using "new" at all (though not on the linked
page), because developers could "forget" to use it. They would write
'var foo = MyObj()' instead of 'var foo = new MyObj()', which would have
unintended consequences.

Quoting from his new book (p49):
| That is really bad. There is no compile warning, and there is no
| runtime warning. This is a serious design error in the language. [...]
| A much better alternative is to not use new at all.
This criticism is repeated later in the "Bad Parts" appendix (p114).
- Conrad
Sep 15 '08 #13

P: n/a
On Sep 15, 4:26*pm, Conrad Lender <crlen...@yahoo.comwrote:
He also advocates never using "new" at all (though not on the linked
page), because developers could "forget" to use it. They would write
'var foo = MyObj()' instead of 'var foo = new MyObj()', which would have
unintended consequences.
There is an easy way to design against this, though, if you're writing
code that will be used in the wild:

function foo (x,y) {
if (!(this instanceof foo))
return new foo(x,y);
this.x = x;
this.y = y;
}

Same design as the RegExp constructor - RegExp("foo","g") and new
RegExp("foo","g") both return RegExp objects.
Sep 16 '08 #14

P: n/a
On Sep 15, 9:21 pm, beegee wrote:
On Sep 15, 10:18 am, Henry wrote:
>On Sep 15, 2:51 pm, beegee wrote:
>>On Sep 14, 5:18 am, Jorge wrote:
>The page referenced above does not suggest that you should
have to get along without using "new", but what is so
necessary about "eval"? (If it is for referencing global
functions using string names then you don't need eval for
that.)
>>(just think about the lack of a <scripttag).
It would save a great deal of time if you would explain what you are
talking about when asked.
>What does that have to do with anything?

Think betterer. How do you include a javascript file?
In WSH?
Now think about how you would do it in a non-browser hosted
environment.
Wouldn't that depend on the environment? You were (though you edited
it from the quoted material without even marking that edit) talking
about WSH.
Honestly, if you know of a way of doing it without eval
then please let me know.
Create the following two files (from the lines between the lines with
the dashes and using the names stated) and put them in the same
directory, and then run test.wsf with WSH:-

---- test.wsf ------------------------------------------------

<job>
<script language="VBScript">
Function doMsgBox(text)
MsgBox text
End Function
</script>
<script language="JScript" src="test.js"></script>
<script language="JScript">
test();
</script>
</job>

--------------------------------------------------------------
---- test.js -------------------------------------------------

doMsgBox('external script loading');

function test(){
doMsgBox('call to external script');
}

--------------------------------------------------------------

- The externally referenced JS files (test.js) (which could be another
wsf file (which could itself load more external files)) is loaded and
can provide resources for the use by scripts in the first file.
You're right about "new" though. He is suggested
deprecating primitive object wrappers, not the use of "new".

On the other hand, I've read as many arguments for the use of semi-
colons as against. Seems like a personal preference.
>Browser scripting has never been Douglas Crockford's expertise
(he is a language expert)

Well, kind of, although his point of reference for last few years
has certainly been browser-side scripting (JSON and it's use in
AJAX seems to have been his major focus).
Unlikely as JSON was well-defined years ago and is not the sort of
thing that needs regular updating.
In his new book, his (and others) main argument against eval,
security, is inapplicable to server side scripting.
That depends entirely on where the thing that is being eval-ed came
from (just as it does in client-side scripting). The only additional
security offered by the server is the fact that a potential attacker
cannot directly observe the use of - eval - in the server side code.
Perhaps his recommendation to deprecate is more to spur
interest in a replacement technology but to do that, OS
hosting must be considered.
What you are calling "OS hosting" is fixed object model scripting,
which is precisely the application where a significantly stricter
language variant can produce the greatest returns.
Sep 16 '08 #15

P: n/a
On Sep 15, 9:11 pm, Conrad Lender wrote:
On 2008-09-15 16:18, Henry wrote:
>On Sep 15, 2:51 pm, beegee wrote:
>>[...] It would be very difficult to get along without
"new" and "eval" in this environment
Where "this environment" was Windows Scripting Host.
>The page referenced above does not suggest that you should
have to get along without using "new", but what is so
necessary about "eval"? (If it is for referencing global
functions using string names then you don't need eval for
that.)

I have found eval() to be useful in two situations: efficient
conversion of a string containing JSON data to an object or
array (if the source of the data can be trusted),
But WSH has files system and database access options so JSON won't
often be relevant.
and evaluating the contents of <scriptelements. The latter
can be necessary when an HTML fragment containing <script>
elements is inserted using innerHTML(), and you want those
scripts to be executed.
<snip>

A seriously unlikely scenario in WSH. And the wisdom of inserting HTML
fragments (at all, and particularly when they include SCRIPT elements)
is questionable.
Sep 16 '08 #16

P: n/a
On Sep 16, 7:04*am, Henry <rcornf...@raindrop.co.ukwrote:
On Sep 15, 9:21 pm, beegee wrote:
On Sep 15, 10:18 am, Henry wrote:
On Sep 15, 2:51 pm, beegee wrote:
(just think about the lack of a <scripttag).

It would save a great deal of time if you would explain what you are
talking about when asked.
You didn't ask anything. This comment was in my first post.
Think betterer. *How do you include a javascript file?

In WSH?
Now think about how you would do it in a non-browser hosted
environment.

Wouldn't that depend on the environment? You were (though you edited
it from the quoted material without even marking that edit) talking
about WSH.
Okay, my requoting was not clear, I do mean WSH.
Honestly, if you know of a way of doing it without eval
then please let me know.
--------------------------------------------------------------
{Your example using a wsf file followed). Thank you. Your example
worked perfectly. I'm not sure what the vbscript was for, I replaced
it with JScript and it worked fine. I was ignorant of wsf files and I
guess your point is that a include mechanism is the responsibility of
the scripting host not the language. In any case, your proof
certainly obviates the need for eval().

In his new book, his (and others) main argument against eval,
security, is inapplicable to server side scripting.

That depends entirely on where the thing that is being eval-ed came
from (just as it does in client-side scripting). The only additional
security offered by the server is the fact that a potential attacker
cannot directly observe the use of - eval - in the server side code.
Well of course, I am assuming that all code, and especially javascript
code is coming from server based files in static libraries. When I say
server-side scripting, I'm talking about maintenance, test suites,
source control, etc. I'm not talking about CGI or web service clients
although I guess one could use JScript for that. I certainly
wouldn't.
Perhaps his recommendation to deprecate is more to spur
interest in a replacement technology but to do that, OS
hosting must be considered.

What you are calling "OS hosting" is fixed object model scripting,
which is precisely the application where a significantly stricter
language variant can produce the greatest returns.
I don't know. That seems a pretty general statement. I doubt
Rubyists, Pythonists or AppleScripters (if your comment was translated
for them) would agree with you.

Bob
Sep 16 '08 #17

P: n/a
Henry wrote:
On Sep 15, 2:51 pm, beegee wrote:
>On Sep 14, 5:18 am, Jorge wrote:
>
Browser scripting has never been Douglas Crockford's expertise (he is
a language expert), and on the whole the ECMA committee working on
ECMAScript revisions seems very lacking in browser centric expertise/
experience (Brendan Eich thinks the authors of dojo qualify as that).
Did Brendan say that?
Garrett
Sep 16 '08 #18

P: n/a
On Sep 16, 6:43*pm, dhtml wrote:
Henry wrote:
>On Sep 15, 2:51 pm, beegee wrote:
>>On Sep 14, 5:18 am, Jorge wrote:
<snip>
>... , and on the whole the ECMA committee working on
ECMAScript revisions seems very lacking in browser centric
expertise/experience (Brendan Eich thinks the authors of dojo
qualify as that).

Did Brendan say that?
<URL: https://mail.mozilla.org/pipermail/e...st/006855.html
>
Sep 17 '08 #19

P: n/a
On Sep 15, 11:48 am, "optimistx" <optimistxPoi...@poistahotmail.com>
wrote:
I did not get it, after 2 minutes of staring.
It's not really possible to figure it out by staring at it. That's
like trying to understand the derivation of a math equation by staring
at the final answer. If you're interested, this is the explanation
that helped me the most: http://www.dreamsongs.com/NewFiles/WhyOfY.pdf
If I were a boss of a group
of programmers, and found one new program maintenance guy
struggling 15 minutes with the above code, I would be a bit angry
with the original coder.
What if he was struggling to understand a basic implementation of a
red/black tree instead? You'd probably tell him to stop wasting his
time and just use it - he doesn't have to know how it works. Not
everyone (unfortunately) has the theoretical background to understand
how a red/black tree works but that doesn't mean they can't use
std::map (to give a c++ example). The Y combinator is a 'library'
function; a couple smart guys who know the theory can implement it and
then everyone else can use it. Just like std::map.

Not that I'm really suggesting that people should be using the Y
combinator in the real world - a reasonable language would always
provide a more efficient means of doing recursion. Javascript is no
different but apparently there is some bug in the JScript
implementation according to some other posters.

Sep 22 '08 #20

P: n/a
On Sep 17, 6:20*am, Henry <rcornf...@raindrop.co.ukwrote:
On Sep 16, 6:43*pm, dhtml wrote:
Henry wrote:
On Sep 15, 2:51 pm, beegee wrote:
On Sep 14, 5:18 am, Jorge wrote:
<snip>
... , and on the whole the ECMA committee working on
ECMAScript revisions seems very lacking in browser centric
expertise/experience (Brendan Eich thinks the authors of dojo
qualify as that).
Did Brendan say that?

<URL:https://mail.mozilla.org/pipermail/e...st/006855.html

Christ on a crutch. Why not ask the jQuery guy for his views on cross-
browser scripting too?

I hope they never finish ES4 (looks like a fair bet at this point.)
Sep 28 '08 #21

P: n/a
On Sep 28, 11:20 pm, David Mark wrote:
On Sep 17, 6:20 am, Henry wrote:
>On Sep 16, 6:43 pm, dhtml wrote:
>>Henry wrote:
<snip>
>>>... , and on the whole the ECMA committee working on
ECMAScript revisions seems very lacking in browser centric
expertise/experience (Brendan Eich thinks the authors of dojo
qualify as that).
>>Did Brendan say that?
>><URL: https://mail.mozilla.org/pipermail/e...st/006855.html

Christ on a crutch. Why not ask the jQuery guy for his views
on cross-browser scripting too?
When Brendan Eich wrote "The Mozilla community's JS hackers let me
know what they think and set me straight often" the odds are that John
Resig is among those being referred to.
I hope they never finish ES4 (looks like a fair bet at this point.)
The odds are still that it will happen eventually, but that it will
not be the thing that it nearly would have been. Given that the
original version could no have been designed with any practical
consideration of its applications taken into account and we managed to
cope with that, it may not matter in the long term if the next version
has as little practical application input into its design. There will
be a more or less painful transition, but that will happen following
any change so only the degree of pain is likely to be considered.
Sep 29 '08 #22

P: n/a
On Sep 29, 12:20*am, David Mark <dmark.cins...@gmail.comwrote:
>
I hope they never finish ES4 (looks like a fair bet at this point.)
I hope they do. Both 3.1 and Harmony, I'm sure it will be for the
better. I just would like them to keep 'callee'... hehe

--
Jorge.
Sep 29 '08 #23

P: n/a
Jorge <jo***@jorgechamorro.comwrites:
[...] I just would like them to keep 'callee'... hehe
Could you, on the other hand, explain your objections to using an
identifier for recursive function expressions? E.g.

<!DOCTYPE script PUBLIC "-//W3C//DTD HTML 4.01//EN">
<script type="text/javascript">
var ms = 200;
window.setTimeout(
function aretha () {
document.body.innerHTML += "$('chain of fools').";
window.setTimeout(aretha, ms);
}, ms
);
</script>

Sep 29 '08 #24

P: n/a
On Sep 30, 12:57*am, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>
wrote:
Jorge <jo...@jorgechamorro.comwrites:
[...] I just would like them to keep 'callee'... hehe

Could you, on the other hand, explain your objections to using an
identifier for recursive function expressions? E.g.

<!DOCTYPE script PUBLIC "-//W3C//DTD HTML 4.01//EN">
<script type="text/javascript">
var ms = 200;
window.setTimeout(
* * * * function aretha () {
* * * * * * * * document.body.innerHTML += "$('I say a little prayer').";
* * * * * * * * window.setTimeout(aretha, ms);
* * * * }, ms
);
</script>
None. Nothing against named functions. Only that there's no need to
use a symbol name if there's no need to. And names shadow other names.
Arguments.callee doesn't. Callee helps introspection (*), callee is
unambiguous, callee helps saving symbol names, callee means 'myself',
not having callee makes anonymous functions less useful than named
ones, callee should stay, I'm going to miss it...

(*) How would you have done this without callee ? : how would you have
discovered which object you're a method of ?

http://jorgechamorro.com/cljs/018/

--
Jorge.
Sep 30 '08 #25

P: n/a
Eric B. Bednarz wrote:
Jorge <jo...@jorgechamorro.comwrites:
[...] I just would like them to keep 'callee'... hehe

Could you, on the other hand, explain your objections to using an
identifier for recursive function expressions? E.g.

<!DOCTYPE script PUBLIC "-//W3C//DTD HTML 4.01//EN">
Eeek.
<script type="text/javascript">
var ms = 200;
window.setTimeout(
function aretha () {
document.body.innerHTML += "$('chain of fools').";
window.setTimeout(aretha, ms);
}, ms
);
</script>
There is a bug in JScript that causes a named function expression to
be evaluated like a function statement; IOW, `aretha' becomes globally
available. For example, try this in the address bar (remove
newlines):

javascript:window.setTimeout(function foo() { window.alert(42); },
1000); window.alert(foo);

Due to the bug, it would first alert the source code of `foo', then
42, in MSHTML (7.0.x); it would (correctly) throw a ReferenceError
exception and then -- interestingly enough -- alert 42, in Gecko
(1.9.0.3).
PointedEars
Sep 30 '08 #26

P: n/a
On Sep 30, 11:33 am, "Thomas 'PointedEars' Lahn" wrote:
Eric B. Bednarz wrote:
>Jorge writes:
>>[...] I just would like them to keep 'callee'... hehe
>Could you, on the other hand, explain your objections to using an
identifier for recursive function expressions? E.g.
><!DOCTYPE script PUBLIC "-//W3C//DTD HTML 4.01//EN">

Eeek.
><script type="text/javascript">
var ms = 200;
window.setTimeout(
function aretha () {
document.body.innerHTML += "$('chain of fools').";
window.setTimeout(aretha, ms);
}, ms
);
</script>

There is a bug in JScript that causes a named function
expression to be evaluated like a function statement; IOW,
`aretha' becomes globally available. For example, try this
in the address bar (remove newlines):
<snip>

More like an out of context function declaration. Or to be more exact;
both like a function declaration and (later) like (or almost like, in
ECMA 262 terms) a function expression. That is, the function that ends
up becoming globally available as 'aretha' is not the same function
(object) as the one that - setTimeout - evaluates (the two function
objects have unique identity).

The possible issues with the proposed ES 3.1 'strict' mode (actually
referred to as the "cautious subset" in the draft specs) not providing
- arguments.callee - should be unrelated to existing JScript bugs
because a new JScript version would be needed before it could be ES
3.1 standard, and hopefully this issue would be fixed in that
version. That would still mean that during a (possibly quite long)
transition period between current ES 3 implementations and future ES
3.1 implementations (with the code attempting to use 'strict' mode
when available) it may not be practical to use either of -
arguments.callee - or named function expressions. But then it is still
not certain that the proposed 'strict' mode will be viable for cross-
browser work (the consequence of the lack of cross-browser code
authoring experience on the committee) and if the 'strict' mode is
only used for scripting known/fixed object models then this may become
a largely academic question for those of us working cross-browsers.
Sep 30 '08 #27

P: n/a
Henry wrote:
"Thomas 'PointedEars' Lahn" wrote:
Eric B. Bednarz wrote:
Jorge writes:
[...] I just would like them to keep 'callee'... hehe
Could you, on the other hand, explain your objections to using an
identifier for recursive function expressions? E.g.
[...]
<script type="text/javascript">
var ms = 200;
window.setTimeout(
* * * * function aretha () {
* * * * * * * * document.body.innerHTML += "$('chainof fools').";
* * * * * * * * window.setTimeout(aretha, ms);
* * * * }, ms
);
</script>
There is a bug in JScript that causes a named function
expression to be evaluated like a function statement; IOW,
`aretha' becomes globally available. *For example, try this
in the address bar (remove newlines):

<snip>

More like an out of context function declaration. Or to be more exact;
both like a function declaration and (later) like (or almost like, in
ECMA 262 terms) a function expression. That is, the function that ends
up becoming globally available as 'aretha' is not the same function
(object) as the one that - setTimeout - evaluates (the two function
objects have unique identity).
Yes, indeed:

javascript:var x = foo; window.alert(x); void
window.setTimeout(function foo() { window.alert(arguments.callee ==
x); }, 1000);

first alerts the source code of foo, then false. What a mess.
The possible issues with the proposed ES 3.1 'strict' mode (actually
referred to as the "cautious subset" in the draft specs) not providing
- arguments.callee - should be unrelated to existing JScript bugs
because a new JScript version would be needed before it could be ES
3.1 standard, and hopefully this issue would be fixed in that
version. [...]
Chances are that this decade will not see ES 3.1 becoming a widely
implemented Web standard, so I do not consider the unnecessary quirks
it introduces in new code yet. And, IMHO, it is completely
unnecessary to deprecate arguments.callee, causing the duplication of
identifiers in source code, and making maintenance harder.
PointedEars
Sep 30 '08 #28

P: n/a
On Sep 30, 2:41*pm, "Thomas 'PointedEars' Lahn" <PointedE...@web.de>
wrote:
>
(...) And, IMHO, it is completely
unnecessary to deprecate arguments.callee, causing the duplication of
identifiers in source code, and making maintenance harder.
Do you have any idea about *why* might they want to deprecate it ?
What's your best guess ?

--
Jorge.
Sep 30 '08 #29

P: n/a
"Thomas 'PointedEars' Lahn" <Po*********@web.dewrites:
Eric B. Bednarz wrote:
There is a bug in JScript that causes a named function expression to
be evaluated like a function statement; IOW, `aretha' becomes globally
available.
Oh my, I didn’t know that. Thanks for the heads up.

Actually, I always used arguments.callee :-), but only in anonymous
functions, and I try to avoid them. Since ES3 explicitly notes the
purpose of a function expression identifier for reference within
the function body, I was wondering why nobody suggested that.
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Oct 2 '08 #30

P: n/a
On Sep 30, 12:33 pm, "Thomas 'PointedEars' Lahn" <PointedE...@web.de>
wrote:
>
There is a bug in JScript that causes a named function expression to
be evaluated like a function statement; IOW, `aretha' becomes globally
available.
On Sep 30, 1:40 pm, Henry <rcornf...@raindrop.co.ukwrote:
>
More like an out of context function declaration. Or to be more exact;
both like a function declaration and (later) like (or almost like, in
ECMA 262 terms) a function expression. That is, the function that ends
up becoming globally available as 'aretha'...( ... )
I just would like to point that it doesn't necessarily 'become
globally available': the name gets (improperly) defined (only) in the
enclosing scope (instead of inside the function itself), but not in
the global scope (that would be wrong as well):

1.- Not 'globally available':
javascript:(function(){setTimeout(function foo() { alert(foo+'\r\n\r
\n'+window.foo);},0); })();

2.- Declared *only* in the outer scope:
javascript:(function(){setTimeout(function foo() { alert(foo); }, 0);
alert(foo); var foo='foo destroyed'; })();

This has already been said before in this very same thread:
http://groups.google.com/group/comp....230e7260b221c4

Thanks,
--
Jorge.
Oct 2 '08 #31

P: n/a
On Oct 2, 10:25*pm, Jorge <jo...@jorgechamorro.comwrote:
>
This has already been said before in this very same thread:http://groups.google.com/group/comp....230e7260b221c4
BTW, if you follow that thread, you'll find as well a workaround by
Brendan Eich (no more no less) :

https://mail.mozilla.org/pipermail/e...er/007498.html

--
Jorge.
Oct 2 '08 #32

P: n/a
On Oct 2, 9:25 pm, Jorge wrote:
On Sep 30, 12:33 pm, "Thomas 'PointedEars' Lahn" wrote:
You have edited out (while failing to indicate that edit) the code
that Thomas was commenting upon. Quoting on Usenet is about providing
a context for responses and removing that context is capable of
significantly altering the reading of comments made in context.

For the sake of clarity this is code that was being commented upon:-

| <script type="text/javascript">
| var ms = 200;
| window.setTimeout(
| function aretha () {
| document.body.innerHTML += "$('chain of fools').";
| window.setTimeout(aretha, ms);
| }, ms
| );
| </script>

- in which we see a function expression using the Identifier "aretha"
being evaluated in a global execution context.

>There is a bug in JScript that causes a named function
expression to be evaluated like a function statement;
IOW, `aretha' becomes globally available.

On Sep 30, 1:40 pm, Henry wrote:
>More like an out of context function declaration. Or to be
more exact; both like a function declaration and (later)
like (or almost like, in ECMA 262 terms) a function expression.
That is, the function that ends up becoming globally available
as 'aretha'...( ... )

I just would like to point that it doesn't necessarily 'become
globally available':
That would depend on what "it" is. In the code that Thomas and I were
commenting upon an "aretha" becomes globally available and is a
reference to a function object.
the name gets (improperly) defined (only) in the
enclosing scope (instead of inside the function itself),
The 'erroneous' processing of the function expression as a function
declaration would have that consequence, as function declarations are
acted upon when entering an execution context, which may be a function
execution context where they would declare a function for that
function execution context's scope.
but not in
the global scope (that would be wrong as well):
In the code in question the function expression appears in the global
execution context, and will have its side effects on the global scope.
1.- Not 'globally available':
javascript:(function(){setTimeout(function foo() { alert(foo+'\r\n\r
\n'+window.foo);},0); })();

2.- Declared *only* in the outer scope:
javascript:(function(){setTimeout(function foo() { alert(foo); }, 0);
alert(foo); var foo='foo destroyed'; })();
<snip>

So you are saying that if the code that was being commented upon had
been some other code than the code being commented upon then the
comments would not necessarily have been accurate? That is so
trivially true that it is not worth anyone's time saying it, or
reading it.
Oct 3 '08 #33

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Jorge wrote:
>Thomas 'PointedEars' Lahn wrote:
>>Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
Jorge wrote:
>[Why deprecate arguments.callee in ES3.1?]
>What's your best guess ?
Insufficient experience of the author of this suggestion.
Come on!
You know it's not *that*,
Do I? You know an awful lot about anyone, don't you?

You must be joking. Brendan Eich, Douglas Crockford, Mark S. Miller,
Maciej Stachowiak, etc... 'insufficient experience' ?

Quite obviously, the author of *this* suggestion is nobody of the mentioned
people.
See the end of:

http://www.crockford.com/javascript/recommend.html

as referenced at the very start of this thread.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Oct 3 '08 #34

P: n/a
On Oct 3, 3:34 pm, Jorge wrote:
On Oct 3, 12:40 pm, Henry wrote:
<snip>
>(rant)
<snip>

I did not write "(rant)".
Oct 3 '08 #35

This discussion thread is closed

Replies have been disabled for this discussion.