FAQ Topic - When should I use eval?

[FAQ server]

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

 

[Evertjan.]

FAQ server wrote on 19 mei 2007 in comp.lang.javascript:

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

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.

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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>

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

 

[Evertjan.]

Dr J R Stockton wrote on 19 mei 2007 in comp.lang.javascript:

In comp.lang.javascript message
<[email protected]> , Sat, 19 May 2007 08:07:36,


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.

 

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

Again, John you miss the point.


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.


--

 

[Evertjan.]

Lee wrote on 20 mei 2007 in comp.lang.javascript:

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

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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>

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.c or a.x.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.