What's wrong with arguments.callee ?
Jorge
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.
Joost Diepenmaat
> 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/
optimistx
> Jorge <jo...@jorgechamorro.com> writes:
>
>> 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?
Jorge
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.
Jorge
> 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/es-discuss/2008-September/007453.html
--
Jorge.
Lasse Reichstein Nielsen
> 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.'
Jorge
wrote:
>
> If it's going to call itself recursively, it shouldn't be anonymous.
>
"it shouldn't be anonymous" because... ?
--
Jorge.
beegee
> 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 <script> tag). 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
Henry
> 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 <script> tag).
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).
optimistx
> 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...).
Conrad Lender
> On Sep 15, 2:51 pm, beegee wrote:
>> "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
<script> elements 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
beegee
> 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 <script> tag).
>
> 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
Conrad Lender
> 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
korisu
> 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.
Henry
> 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 <script> tag).
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.
Henry
> 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 <script> elements. 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.
beegee
> 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 <script> tag).
>
> 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
dhtml
Did Brendan say that?
Garrett
Henry
> Henry wrote:
>> On Sep 15, 2:51 pm, beegee wrote:
>>> On Sep 14, 5:18 am, Jorge wrote:
>> ... , and on the whole the ECMA committee working on
>> ECMAScript revisions seems very lacking in browser centric
>> qualify as that).
>
> Did Brendan say that?
<URL: https://mail.mozilla.org/pipermail/es-discuss/2008-August/006855.html
>
carton
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.
David Mark
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.)
Henry
> 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/es-discuss/2008-August/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.
Jorge
>
> 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.
Eric B. Bednarz
> [...] 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>
Jorge
wrote:
> Jorge <jo...@jorgechamorro.com> 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">
> <script type="text/javascript">
> var ms = 200;
> window.setTimeout(
> function aretha () {
> 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.
Thomas 'PointedEars' Lahn
> Jorge <jo...@jorgechamorro.com> 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):
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
Henry
> Eric B. Bednarz wrote:
>>> [...] 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):
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.
Thomas 'PointedEars' Lahn
> "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 += "$('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).
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
Jorge
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.
Thomas 'PointedEars' Lahn
> "Thomas 'PointedEars' Lahn" 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 ?
See <http://wiki.ecmascript.org/doku.php?id=es3.1:arguments.callee&s=callee>
One wonders what the "significant new value" (design priciple 2b) of using
identifiers that are references to Function objects are, when compared
against arguments.callee. One also wonders why it is necessary to do this
in order to achieve the goals of ES 3.1.
> What's your best guess ?
Insufficient experience of the author of this suggestion.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jorge
wrote:
> Jorge wrote:
> > "Thomas 'PointedEars' Lahn" 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 ?
>
> See <http://wiki.ecmascript.org/doku.php?id=es3.1:arguments.callee&s=callee>
>
> One wonders what the "significant new value" (design priciple 2b) of using
> identifiers that are references to Function objects are, when compared
> against arguments.callee. One also wonders why it is necessary to do this
> in order to achieve the goals of ES 3.1.
>
> > What's your best guess ?
>
> Insufficient experience of the author of this suggestion.
Come on!
You know it's not *that*, it has to be something else.
--
Jorge.
Eric B. Bednarz
> 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
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jorge wrote:
>>> "Thomas 'PointedEars' Lahn" 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 ?
>> See <http://wiki.ecmascript.org/doku.php?id=es3.1:arguments.callee&s=callee>
>>
>> One wonders what the "significant new value" (design priciple 2b) of using
>> identifiers that are references to Function objects are, when compared
>> against arguments.callee. One also wonders why it is necessary to do this
>> in order to achieve the goals of ES 3.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?
> it has to be something else.
Does it? How is this suggestion going to
- help achieving goal 1 of ES3.1, that is "Browser implementation
unification: Consider adopting features that are already implemented in 3
of the 4 browser brands, or that are deployed in 3 out 4 user computers
and reduce cross browser incompatibilities.", given that arguments.callee
is widely supported already and that we know of the JScript peculiarity
with named function expressions?
and to
- meet design principle 2b, that is to "Offer significant new value"?
Jorge
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.uk> 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': 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.lang.javascript/msg/fa230e7260b221c4
Thanks,
--
Jorge.
Jorge
wrote:
> Jorge wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Jorge wrote:
> >>> "Thomas 'PointedEars' Lahn" 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 ?
> >> See <http://wiki.ecmascript.org/doku.php?id=es3.1:arguments.callee&s=callee>
>
> >> One wonders what the "significant new value" (design priciple 2b) of using
> >> identifiers that are references to Function objects are, when compared
> >> against arguments.callee. One also wonders why it is necessary to do this
> >> in order to achieve the goals of ES 3.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' ?
> > it has to be something else.
>
> Does it? How is this suggestion going to
>
> - help achieving goal 1 of ES3.1, that is "Browser implementation
> unification: Consider adopting features that are already implemented in 3
> of the 4 browser brands, or that are deployed in 3 out 4 user computers
> and reduce cross browser incompatibilities.", given that arguments.callee
> is widely supported already and that we know of the JScript peculiarity
> with named function expressions?
>
> and to
>
> - meet design principle 2b, that is to "Offer significant new value"?
I'm not sure, but I think that it might most likely have to do with
some obscure security issue.
See the (long) list of features (even 'this' !) that Crockford chose
to remove in order to achieve 'safety':
http://www.adsafe.org/
Or maybe it hinders certain foreseeable optimizations in the
compilers ?
Or... ?
--
Jorge.
Jorge
>
> This has already been said before in this very same thread:http://groups.google.com/group/comp.lang.javascript/msg/fa230e7260b221c4
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/es-discuss/2008-September/007498.html
--
Jorge.
Henry
> 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.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jorge wrote:
>>> Thomas 'PointedEars' Lahn 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.
>>> it has to be something else.
>> Does it? How is this suggestion going to
>>
>> - help achieving goal 1 of ES3.1, [...]
>> - meet design principle 2b, that is to "Offer significant new value"?
>
> I'm not sure, but I think that it might most likely have to do with
> some obscure security issue.
> See the (long) list of features (even 'this' !) that Crockford chose
> to remove in order to achieve 'safety':
> http://www.adsafe.org/
>
> Or maybe it hinders certain foreseeable optimizations in the
> compilers ?
>
> Or... ?
I don't know about you, but I find plain guessing games tiresome.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Joost Diepenmaat
> 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/
Thomas 'PointedEars' Lahn
Sigh. [psf 10.1] Douglas Crockford is not, I repeat, *not* the author of
*this* suggestion in the ES3.1 proposal (the real author can readily be
determined by the Wiki articles's signature). While the author of *this*
suggestion might derive it from the authority (instead of the reasoning) of
Douglas Crockford (because the latter does not give any reason for this
recommendation there, and those are altogether recommendations for
ECMAScript Ed. *4 from last year* anyway), it is the arguments given in the
Wiki article that are in question here.
Read, think, post. In that order.
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>
Jorge
>
> (rant)
>
Sorry, but reading (only) your posts it wasn't clear enough (IMHO)
whether that bug had something to do with 'global availability' or
not. I would have preferred not having to boot Windozes in a VM in my
Mac in order to run IE (grrr) in order to test it, but I couldn't
resist the joy of watching (one more time) what the M$ company is able
to do with so many M$'s and service packs... hehe.
--
Jorge.
Henry
> On Oct 3, 12:40 pm, Henry wrote:
<snip>
>> (rant)
<snip>
I did not write "(rant)".
Dr J R Stockton
3 Oct 2008 14:55:51, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>
>Read, think, post. In that order.
>
Incorrect. Read, think, write, think, post.
--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
alje...@gmail.com
Ry Nohryb
> I bloody hate this idea, someone really needs to start a petition or smthn to keep arguments.callee
Yeah, LOL.
--
( Jorge )();
Michael Haufe (TNO)
> I bloody hate this idea, someone really needs to start a petition or smthn to keep arguments.callee
Have you read any of the history and reasoning on es-discuss yet?
Thomas 'PointedEars' Lahn
follows up to a five year old thread without a substantial argument.
For that matter, have *you* been reading the thread in which you are
posting? It has been pointed out there that there are disadvantages of
_not_ using arguments.callee. At least as long as the relevant JScript
versions are around. But arguments.callee is not dead, it has just been
made forbidden in ES 5 strict mode.
That said, since I have not been reading es-discuss either (I do not have
the time), I would be grateful, and I expect other readers would, if you
could provide (a) relevant URI(s).
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Michael Haufe (TNO)
>
> I think you are expecting too much of an anonymous Google poster who
> follows up to a five year old thread without a substantial argument.
> For that matter, have *you* been reading the thread in which you are
> posting? It has been pointed out there that there are disadvantages of
> _not_ using arguments.callee. At least as long as the relevant JScript
> versions are around. But arguments.callee is not dead, it has just been
> made forbidden in ES 5 strict mode.
> That said, since I have not been reading es-discuss either (I do not have
> the time), I would be grateful, and I expect other readers would, if you
> could provide (a) relevant URI(s).
Michael Haufe (TNO)
points of discussion. While I have attempted to maintain the context while
taking quotes (or paraphrasing/snipping/expanding in [square brackets]),
It is entirely possible some relevant context/detail was missed. Do indeed
read the respective threads for yourself to see who made the individual quotes
and for the full context. Quite a bit has been left out as you'd suspect
The convention below is
<url>
summary comment
Apologies in advance if Google Groups butchers the format slightly. And no,
I have no intention of installing new software or creating a new account
through another service.
<https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002909.html>
"F often passes its "arguments" to G in order to give G access to the
actual arguments it was called with. Just as strict mode protects F against
G thereby modifying F's parameter variables (by not joining), the
arguments.callee poison pill protects F from inadvertently leaking itself to
G."
<https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002911.html>
"[...] F could prevent this leakage by simply deleting the callee property"
<https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002913.html>
"F could likewise prevent G from modifying F's parameter variables by,
for example, passing out 'Array.slice(arguments, 0)' rather than
'arguments'. The point of 'use strict' is to say 'I want the following
code to operate in a somewhat saner and safer language where I don't
have to worry as much about accidental leakage.' Having remembered to
say 'use strict', the programmer should be relieved of saying 'delete
arguments.callee' or 'Array.slice(arguments, 0)'."
<https://mail.mozilla.org/pipermail/es5-discuss/2008-September/001882.html>
"The arguments object itself is often passed in order for function F to
give function G access to the argument list F with which was called.
This seemingly innocent operation should not also inadvertently
provide G with the ability to call F. F might otherwise be
encapsulated within some larger abstraction."
<https://mail.mozilla.org/pipermail/es5-discuss/2008-September/001883.html>
"Hmm, the problem is 'callee' being a property of 'arguments' ?
or the functionality that 'callee' provides ?
IOW, could we have instead a ('standalone') 'callee' property (that
isn't to be innocently passed on) ?"
<https://mail.mozilla.org/pipermail/es5-discuss/2008-September/001884.html>
"...as a property of what?
Any magically bound variable breaks [Tennant's Correspondence]. The expression
callee
should have the same meaning as
(function() { return callee; })()
...and it clearly does not."
<https://mail.mozilla.org/pipermail/es5-discuss/2008-September/001885.html>
[who cares?]
<https://mail.mozilla.org/pipermail/es5-discuss/2008-September/001886.html>
"Just name your function. By itself, this is as convenient -- as well
as more understandable -- as any of the 'conveniences' that have been
proposed to help with this non-problem."
<https://mail.mozilla.org/pipermail/es5-discuss/2008-September/001889.html>
"It's not worth it, especially if you want just
callee (use a named function expression, or bind an outer lexical
name) or caller (stack inspection should be served by a carefully
designed API on the side -- 'mirror' reflection, not an API on
activation objects)."
<https://mail.mozilla.org/pipermail/es-discuss/2011-January/012502.html>
"I can appreciate the security concerns of passing the arguments object
as a parameter to another method, but why not make that the 'red flag'
action rather than nixing 'arguments' entirely?"
<https://mail.mozilla.org/pipermail/es-discuss/2011-January/012506.html>
"IE, prior to IE9, didn't conform to the standard for function
expressions and makes the name 'func' visible in the surrounding
scope. However, if all you want to do if be able to refer to 'func'
within the {...} body and not interfere with any declarations in the
surrounding scope, even for IE <= 8, you can usually accomplish this
by choosing a unique name instead of "func" that is highly unlike to
be used in the surrounding scope."
<https://mail.mozilla.org/pipermail/es-discuss/2011-January/012508.html>
"IE<9 actually creates 2 function objects when parsing NFE; not just leaks
identifier to the enclosing scope. It might seem irrelevant at first, but if
you consider that something like 'var f = function g(){ ... } ' will result
in creation of 2 distinct function objects bound to 'f' and 'g' [...]"
<https://mail.mozilla.org/pipermail/es-discuss/2011-January/012509.html>
"Yes, there is more too it, as [pointed] out. But I think we are at the
point where we are just adding noise to this conversation. [...] A named
function expression with a well chosen name is a very interoperable way
to easily do this. All the other semantic subtleties and implementation
variations in the handling of block nested declarations are not really
all that relevant to straight-forward usage of that pattern."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009874.html>
"Using named functions isn't a solution for us because it
would break IE compatibility. [...] Right now I don't see a good solution
for this in strict mode."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009878.html>
"But strict mode is not supported in current or downrev IE."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009881.html>
"Wouldn't that violate the principle of strict mode? I thought the
idea was that writing code in Harmony could basically boil down to ES3
code if I wanted to. But in this case it wouldn't; the same code
written for Harmony would appear valid ES3 but would fail."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009885.html>
"IE fixing bad old named function expression bugs
violates nothing, not ES5 or ES5 strict, and certainly not ES3 which
spec'ed how named function expressions bind their names [...]"
[...]
"You have to test to see that "use strict"; code works the way
you expect in older browsers. If you steer clear of arguments objects
you don't have much to do."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009890.html>
"But just to be clear, after all of the discussion here, it appears
that the only way to implement a 'call super' pattern in ES5 (without
resorting to closures [...]) would be to use the
following magic phrase everywhere I want to invoke super:
var IS_ES5_STRICT = /** detect ES5 strict mode somehow */
ClassB = ClassA.extend({
foo: function method() {
(IS_ES5_STRICT ? method : arguments.callee).base.apply(this,
arguments);
}
});
Keep in mind that since I need to know the current function instance,
I can't abstract this code into a function. Everyone will just have
to know this magic phrase to 'call super'."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009891.html>
"But why wouldn't you use method always? [...] Agree it's annoying to
have to add six letters of cruft after the function keyword (with space
separator) but once you do that, provided you dodge IE bugs, why do you
need arguments.callee at all?"
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009908.html>
"If I were a poor woodcutter who couldn't afford his own preprocessing
tools, I would probably just write:
ClassB.foo.base.apply(this, arguments)"
<https://mail.mozilla.org/pipermail/es-discuss/2010-January/010514.html>
"I suggest avoiding super calls. If you really must, then consider a
standard approach that will work consistently across browsers, and in
ES3 and ES5 strict:
ClassB.prototype = {
foo: function() {
ClassA.prototype.foo.call(this);
}
};"
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009858.html>
"I'm curious, why not just give anonymous functions a default name like
'callee'. Or perhaps have 'callee' defined in a function scope to
represent the function? That seems to be exactly the same as the
above; it just makes it easier for developers. Is there a perf issue
here?"
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009859.html>
"No, there's simply a backward compatibility problem. Anonymous
functions do not inject any such name on the scope chain (in any
object, new or expected, on the scope chain). Changing the language to
inject callee (even in an ES5 declarative envirnment frame) is not
backward compatible and probably will break some content out there
that uses callee in an outer scope to mean something else."
<https://mail.mozilla.org/pipermail/es-discuss/2009-September/009868.html>
"It seems like the argument against it is security:
if I pass you my arguments object, you now have access to the original
function, which violates the POLA.
Isn't the fact [...] that
arguments.callee can be deleted a mitigating factor here?
Aren't there other fixes that would work as well (such as making
arguments.callee only available lexically) without completely removing the
feature."
<https://mail.mozilla.org/pipermail/es-discuss/2013-March/029187.html>
[in reference to <https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-01/jan-30.md>]
"[...] arrows can't have intrinsic names (contrast with NFEs) so
arguments.callee may be wanted, so arrows should not be strict-only."
<https://mail.mozilla.org/pipermail/es-discuss/2013-March/029188.html>
"I think this is a better argument for introducing a new primitive for
referencing the current function than for resurrecting arguments."
Déjà vu?
Ben Bacarisse
<snip>
> points of discussion.
Thank you for your effort. Very interesting. (The discussion is
actually new to me.)
--
Ben.
JJ
> "F often passes its "arguments" to G in order to give G access to the
> actual arguments it was called with. Just as strict mode protects F against
> G thereby modifying F's parameter variables (by not joining), the
> arguments.callee poison pill protects F from inadvertently leaking itself to
> G."
data is leaked to G. Could you give a simple example code, please?
Michael Haufe (TNO)
> Sorry, I'm not quite good at English and can't understand which part where
> data is leaked to G. Could you give a simple example code, please?
console.log([" x:",x," y:",y," z:",z].join(""))
g(arguments);
console.log([" x:",x," y:",y," z:",z].join(""))
}
function g(args){
args[0] = "foo"
args[1] = "bar"
args[2] = args.callee
}
f(1,2,3)
Thomas 'PointedEars' Lahn
function f (x, y, z)
{
"use strict";
/* x: "1, y: 2, z: 3" */
console.log(["x: ", x, " y: ", y, " z: ", z].join(""));
g(arguments);
/* x: "1, y: 2, z: 3" */
console.log(["x: ",x," y: ", y, " z: ", z].join(""));
}
function g (args)
args[0] = "foo"
args[1] = "bar"
}
f(1, 2, 3);
Therefore, it was _not_ necessary to forbid arguments.callee in strict mode.
Thomas 'PointedEars' Lahn
function f (x, y, z)
{
"use strict";
g(arguments);
/* "x: 1, y: 2, z: 3" */
console.log(["x: ", x, " y: ", y, " z: ", z].join(""));
}
args[0] = "foo"
args[1] = "bar"
}
f(1, 2, 3);
Therefore, it was _not_ necessary to forbid arguments.callee in strict mode.
Archenoth
> 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.
You can have an inline named function like so:
> setTimeout( function loop() {
> (...)
> setTimeout( loop, ms );
> }, ms );
Early versions of the language never allowed for named functions as expressions, which made anonymous recursion impossible. So, to allow for this sort of recursion, arguments.callee was born as a bit of a quick-fix. But now that that has been remedied, there is little reason to use it. (Aside from taking up a name in the namespace within the current scope.)
I had many uses for arguments.callee too, but upon further investigation, it seems as though inline named functions solve all of the problems I had before, and allow for some other nifty little constructs.
Thomas 'PointedEars' Lahn
> On Sunday, September 14, 2008 3:18:03 AM UTC-6, Jorge wrote:
Good morning.
>> 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.
>
> You can have an inline named function like so:
>
>> setTimeout( function loop() {
>> (...)
>> setTimeout( loop, ms );
>> }, ms );
>
> Early versions of the language never allowed for named functions as
> expressions, which made anonymous recursion impossible. So, to allow for
> this sort of recursion, arguments.callee was born as a bit of a quick-fix.
If “the language” is supposed to be Netscape JavaScript (not the only
ECMAScript implementation that is on-topic here), then know that
arguments.callee was introduced with JavaScript 1.2 in Netscape Navigator
4.0 –
<http://faqintosh.com/risorse/web/netscape/CoreReferenceJS14/function.htm>
– and so were function expressions, *both* anonymous and named (AFAIK the
proof is in the pudding only; should it be possible to make the ECMAScript
Support Matrix 2 that much backwards-compatible, those test results will be
contained in there).
> But now that that has been remedied,
decision that is being discussed in this thread.
> there is little reason to use it. (Aside from taking up a name in the
> namespace within the current scope.)
>
> I had many uses for arguments.callee too, but upon further investigation,
> it seems as though inline named functions solve all of the problems I had
> before, and allow for some other nifty little constructs.
*that* old). TIA.