469,322 Members | 1,564 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,322 developers. It's quick & easy.

FAQ Topic - When should I use eval?

-----------------------------------------------------------------------
FAQ Topic - When should I use eval?
-----------------------------------------------------------------------

The ` eval() ` function should _only_ be used when it is necessary to
evaluate a string supplied or composed at run-time; the string
can be anything from a simple (but unpredictable) expression such
as 12*2.54 to a substantial piece of javascript code.

The ` eval() ` function should not be used as a crutch in composing
member expressions; see section 4.39.
===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://jibbering.com/faq/index.html.
The FAQ workers are a group of volunteers.

May 18 '07 #1
8 1958
FAQ server wrote on 19 mei 2007 in comp.lang.javascript:
-----------------------------------------------------------------------
FAQ Topic - When should I use eval?
-----------------------------------------------------------------------

The ` eval() ` function should _only_ be used when it is necessary to
evaluate a string supplied or composed at run-time;
"at run-time" should be reserved for compiler languages, methinks.

Perhaps "during execution"?

Suggestion:
"eval() should only be used for executing expressions supplied by the
client user."
the string
can be anything from a simple (but unpredictable) expression such
as 12*2.54 to a substantial piece of javascript code.
Even then, when only a limited number of operators [*,-,+,/,etc.] is
expected to be inputted by the user in a string, dedicated parsing of
that string could be safer. The writing of such simple dedicated parsers
is fun and educational.
The ` eval() ` function should not be used as a crutch in composing
member expressions; see section 4.39.
"As a crutch"?
Please do not use local native idiom in the FAQ.
Keep to "simple English".

What is a "member expression"?
What is ment by "composing"?

eval() is for executing unexpected expressions,
not composing them.
Perhaps I do not understand this expression,
because I am not a "member"?

==============

A warning for using eval() in js environments
with [intentionally] lowered security should be added.

A warning for using eval() in a serverside js environment
should be added.

A warning that EACH eval() execution, by setting up a seperate engine,
lowers the execution speed and needs a lot of extra memory, especially
when used in a loop, should be added.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
May 19 '07 #2
Evertjan. said the following on 5/19/2007 4:07 AM:
FAQ server wrote on 19 mei 2007 in comp.lang.javascript:
>-----------------------------------------------------------------------
FAQ Topic - When should I use eval?
-----------------------------------------------------------------------

The ` eval() ` function should _only_ be used when it is necessary to
evaluate a string supplied or composed at run-time;

"at run-time" should be reserved for compiler languages, methinks.

Perhaps "during execution"?

Suggestion:
"eval() should only be used for executing expressions supplied by the
client user."
The problem is that isn't entirely true. The original is very true. The
reason I say that? I had a very simple scenario where I was converting
fractions to decimals (there is an old thread somewhere where I posted
about it) that came from a select list. The quickest way to convert them
was to eval the value of the select list. So saying only expressions
supplied by the client user is far off the mark.

<URL:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/88a3a41b107b98d8/452824d170405e83?lnk=gst&q=fraction+decimal+eval+s elect&rnum=1#452824d170405e83>

Although IE7 gives closer results on the test page in there.
>the string
can be anything from a simple (but unpredictable) expression such
as 12*2.54 to a substantial piece of javascript code.

Even then, when only a limited number of operators [*,-,+,/,etc.] is
expected to be inputted by the user in a string, dedicated parsing of
that string could be safer. The writing of such simple dedicated parsers
is fun and educational.
It would definitely be safer :-)
>The ` eval() ` function should not be used as a crutch in composing
member expressions; see section 4.39.

"As a crutch"?
Please do not use local native idiom in the FAQ.
Keep to "simple English".
That line has been in there so long and I had honestly not paid
attention to it. It has been removed from my local copy.
A warning for using eval() in js environments
with [intentionally] lowered security should be added.
How can an author be expected to know the security settings of the
browser though?
A warning for using eval() in a serverside js environment
should be added.
Wouldn't that be more appropriate in a serverside JS faq though? I know
the FAQ (and group) cover both but you don't see a whole lot of server
side JS questions here. And a lot of the ones you do see usually get
redirected to a server side JS group.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 19 '07 #3
Randy Webb wrote on 19 mei 2007 in comp.lang.javascript:
>A warning for using eval() in js environments
with [intentionally] lowered security should be added.

How can an author be expected to know the security settings of the
browser though?
If he/she writes a page primarily for his own browser or for a small group
of users. But you are right, it is an exception.
>A warning for using eval() in a serverside js environment
should be added.

Wouldn't that be more appropriate in a serverside JS faq though? I know
the FAQ (and group) cover both but you don't see a whole lot of server
side JS questions here. And a lot of the ones you do see usually get
redirected to a server side JS group.
On the other hand, it is extremely dangerous, apar with SQL injection,
so it would not hurt to warn the unsuspecting newcomer of serverside js,
still getting his/her information from this FAQ.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
May 19 '07 #4
In comp.lang.javascript message <Xn********************@194.109.133.242>
, Sat, 19 May 2007 08:07:36, Evertjan. <ex**************@interxnl.net>
posted:
>The ` eval() ` function should not be used as a crutch in composing
member expressions; see section 4.39.

"As a crutch"?
Please do not use local native idiom in the FAQ.
Keep to "simple English".

What is a "member expression"?
What is ment by "composing"?
But "crutch" is a standard English word, and you must have a local
equivalent. Just ask any Dutchman with about half the average number of
legs; he may well reply "steunpilaar". It's "Kru:cke" is German, if the
slipped umlaut is replaced. Of course, "crutch" does have another
meaning; but that is clearly inapplicable.

And "composing" is also standard, and not restricted to music.

And "member" and "expression" are standard English words, with
applicable meaning. In ISO/IEC 16262, "member expression" admittedly
does not appear; but "MemberExpression" occurs 26 times. I expect the
term was imported after reading RC's writing.
Hah! If the sentence is translated to Dutch by Babel Fish, the result
contains "niet" and looks plausible. But on translating back I got "The
function ` eval () ` as a support pill ear must be used in composing
member expressions; see section 4.39." The negative is lost. Strange.
The sentence could of course be changed; but ISTM that the meaning, and
strength, should remain.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.
May 19 '07 #5
Dr J R Stockton wrote on 19 mei 2007 in comp.lang.javascript:
In comp.lang.javascript message
<Xn********************@194.109.133.242, Sat, 19 May 2007 08:07:36,
Evertjan. <ex**************@interxnl.netposted:
>>The ` eval() ` function should not be used as a crutch in composing
member expressions; see section 4.39.

"As a crutch"?
Please do not use local native idiom in the FAQ.
Keep to "simple English".

What is a "member expression"?
What is ment by "composing"?

But "crutch" is a standard English word, and you must have a local
equivalent. Just ask any Dutchman with about half the average number
of legs; he may well reply "steunpilaar".
He would not [your name would be bab(b)lefisch], but that is beside the
point.

Using crutch for a way to keep a piece of code "standing" is idiomatic.
It's "Krücke" is German,
if the slipped umlaut is replaced. Of course, "crutch" does have
another meaning; but that is clearly inapplicable.

And "composing" is also standard, and not restricted to music.
Again, John you miss the point.
And "member" and "expression" are standard English words, with
applicable meaning. In ISO/IEC 16262, "member expression" admittedly
does not appear; but "MemberExpression" occurs 26 times. I expect the
term was imported after reading RC's writing.
It is not that the words are not standard, If they were not they could be
called "slang" or "dialect", it is that they are used in an idiomatic
composition.

"member expression", member of what?
Did the expression pay a membership fee?
If not, the expression is either in debt or the sentence is idiomatic.
Hah! If the sentence is translated to Dutch by Babel Fish, the result
contains "niet" and looks plausible. But on translating back I got
"The function ` eval () ` as a support pill ear must be used in
composing member expressions; see section 4.39." The negative is
lost. Strange.
Again you miss my point.

The higher educated Dutch on the whole are quite capable of understanding
English idiom, because in secondary schools up to 6 languages can be and
often are learned, and as Anglo-saxon idiom often overlaps with Dutch
idiom, a large part of language teaching is to learn where that overlap
is absent. There are many jokes about those pseudo-overlaps among
polyglots, that monoglots dismally fail to appriciate. As a confessed
polyglot you should know of those jokes.

The cyberworld is bigger than English and Dutch.
The sentence could of course be changed; but ISTM that the meaning,
and strength, should remain.
I submit that the FAQ should be in simple English to be accessable to as
many people as possible.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
May 20 '07 #6
Lee
Evertjan. said:
>Using crutch for a way to keep a piece of code "standing" is idiomatic.
It's a very commonly used metaphor. If you understand what
a crutch is, you should be able to understand the meaning.
I can't imagine understanding English well enough to make
any sense of the FAQ without having come across it several
times.

>It's "Krücke" is German,
if the slipped umlaut is replaced. Of course, "crutch" does have
another meaning; but that is clearly inapplicable.

And "composing" is also standard, and not restricted to music.

Again, John you miss the point.
>And "member" and "expression" are standard English words, with
applicable meaning. In ISO/IEC 16262, "member expression" admittedly
does not appear; but "MemberExpression" occurs 26 times. I expect the
term was imported after reading RC's writing.

It is not that the words are not standard, If they were not they could be
called "slang" or "dialect", it is that they are used in an idiomatic
composition.

"member expression", member of what?
Did the expression pay a membership fee?
If not, the expression is either in debt or the sentence is idiomatic.
"member" in this sense isn't idiomatic, it's a correct technical
term for an attribute of an object.

If you seriously have problems understanding "composing an expression",
then there's a deficiency in your own English language education that
doesn't justify a change to the FAQ.

>I submit that the FAQ should be in simple English to be accessable to as
many people as possible.
Nothing should ever be dumbed down to the point of being accessible
to as many people as possible. The FAQ should be written to be
readable by the people who are frequently asking the questions.

"should not be used as a crutch in composing member expressions"
is very clear and concise. Following the instructions to see
section 4.39 should clear up any confusion about what a "member
expression" is.
--

May 20 '07 #7
Lee wrote on 20 mei 2007 in comp.lang.javascript:
>>It is not that the words are not standard, If they were not they could
be called "slang" or "dialect", it is that they are used in an
idiomatic composition.

"member expression", member of what?
Did the expression pay a membership fee?
If not, the expression is either in debt or the sentence is idiomatic.

"member" in this sense isn't idiomatic, it's a correct technical
term for an attribute of an object.
Not however, if the words attribute and object are only inferred
and if they were explicitly used, the word member would be superfluous.
[see below.]
If you seriously have problems understanding "composing an
expression", then there's a deficiency in your own English language
education that doesn't justify a change to the FAQ.
Why would you think my(!!!) English cannot understand that if I have
doubt that all FAQ users understand?

Should we leave the complaining about difficult language to the users
that have trouble, you probably will not hear a thing.
>>I submit that the FAQ should be in simple English to be accessable to
as many people as possible.

Nothing should ever be dumbed down to the point of being accessible
to as many people as possible.
Your exageration. Why ridicule a completely reasonable submission without
giving any reasons?
The FAQ should be written to be
readable by the people who are frequently asking the questions.
Why?

I don't see any reason that beginners shouldn't just use the FAQ.

So if one has problems with writing a Q in English,
the much simpler task of reading it should be made impossible?
"should not be used as a crutch in composing member expressions"
is very clear
I don't agree.
and concise.
So?
Following the instructions to see
section 4.39 should clear up any confusion about what a "member
expression" is.
No. A pointer to another section should not be used to clear up
misunderstandings about the text.

I propose:
The ` eval() ` function should not be used as a crutch
in composing member expressions; see section 4.39.
The `eval()` function should not be used to compose
member attributes of an object
; section 4.39 shows the better way.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
May 20 '07 #8
In comp.lang.javascript message <Xn********************@194.109.133.242>
, Sun, 20 May 2007 17:23:47, Evertjan. <ex**************@interxnl.net>
posted:
>
>The ` eval() ` function should not be used as a crutch
in composing member expressions; see section 4.39.

The `eval()` function should not be used to compose
member attributes of an object
; section 4.39 shows the better way.
But attributes are not, in the case in mind, being composed. What is
being composed is an expression yielding a reference (address or pointer
or similar, in effect) which can be used to refer to an attribute,
property, or suchlike.

However, it could be necessary to use eval, or a construction
substantively equivalent, if it is essential to evaluate something only
supplied at run-time. The case that is mainly on mind is where
something like eval("a." + b + ".c") could be used but something
like a[b].c or a.x[b].c is better.

There's nothing wrong, sometimes, in using eval to access attributes;
only in using it in the manner of a crutch instead of walking properly.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.
May 20 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Nathan Sokalski | last post: by
3 posts views Thread by FAQ server | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Gurmeet2796 | last post: by
reply views Thread by mdpf | last post: by
reply views Thread by harlem98 | last post: by
reply views Thread by listenups61195 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.