What's wrong with arguments.callee ?

[Jorge]

Why is it listed here :

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

under "deprecatio n" ?

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

I use to write timers like this :

setTimeout( function () {
(...)
setTimeout( arguments.calle e, ms );
}, ms );

How am I suppossed to do that without arguments.calle e ?

Thanks,
--
Jorge.

[Joost Diepenmaat]

Re: What's wrong with arguments.calle e ?

Jorge <jorge@jorgecha morro.comwrites :

Why is it listed here :
>

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

>
under "deprecatio n" ?

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]

Re: What's wrong with arguments.calle e ?

Joost Diepenmaat wrote:

Jorge <jorge@jorgecha morro.comwrites :
>

>Why is it listed here :
>>
>http://www.crockford.com/javascript/recommend.html
>>
>under "deprecatio n" ?

>
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]

Re: What's wrong with arguments.calle e ?

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.calle e is 100% unambiguous,
while functionName might not.

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

--
Jorge.

[Jorge]

Re: What's wrong with arguments.calle e ?

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/es-discuss/2008-September/007453.html

--
Jorge.

[Lasse Reichstein Nielsen]

Re: What's wrong with arguments.calle e ?

Jorge <jorge@jorgecha morro.comwrites :

Why is it listed here :
>

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

>
under "deprecatio n" ?
>
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.calle e, ms );
}, ms );
>

setTimeout(func tion rec() {
(...)
setTimeout(rec, ms);
}, ms);

(or use setInterval)


/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jorge]

Re: What's wrong with arguments.calle e ?

On Sep 14, 9:46 pm, Lasse Reichstein Nielsen <lrn.unr...@gma il.com>
wrote:

>
If it's going to call itself recursively, it shouldn't be anonymous.
>

"it shouldn't be anonymous" because... ?

--
Jorge.

[beegee]

Re: What's wrong with arguments.calle e ?

On Sep 14, 5:18 am, Jorge <jo...@jorgecha morro.comwrote:

Why is it listed here :
>

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

>
under "deprecatio n" ?
>

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

[Henry]

Re: What's wrong with arguments.calle e ?

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 "deprecatio n" ?

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

[optimistx]

Re: What's wrong with arguments.calle e ?

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.calle e 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.niceNameO fMyFunction = function () {
alert ('I try to be very nice and friendly towards everyone');
}

JORGE.goodDescr iptiveName = 'property value';

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

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]

Re: What's wrong with arguments.calle e ?

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
<scriptelemen ts 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 counterproducti ve. His aversion against the "new" operator and
his unconditional preference of function expressions vs. function
statements would be two examples.


- Conrad

[beegee]

Re: What's wrong with arguments.calle e ?

On Sep 15, 10:18 am, Henry <rcornf...@rain drop.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

[Conrad Lender]

Re: What's wrong with arguments.calle e ?

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

[korisu]

Re: What's wrong with arguments.calle e ?

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.

[Henry]

Re: What's wrong with arguments.calle e ?

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="VBScr ipt">
Function doMsgBox(text)
MsgBox text
End Function
</script>
<script language="JScri pt" src="test.js"></script>
<script language="JScri pt">
test();
</script>
</job>

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

doMsgBox('exter nal 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.