eval alternative

[Jeff]

I have an event that I wish to pass a javascript array.

And I was thinking of using eval

onchange = "passArray('some_array')"

function passArray(arr){
var my_array = eval(arr);
....

I rarely use eval, is there a real downside to this? Eval routinely
gets savaged. This is server generated code and I would prefer not to
generate the array until below where the link is written. So if I did this:

(I think this is the right syntax)

onchange = "passArray("+some_array+")"

Then it wouldn't be defined yet.

Is there a better way to do this?

Jeff

 

[David Mark]

   I have an event that I wish to pass a javascript array.

   And I was thinking of using eval

onchange = "passArray('some_array')"

Are you planning to eval this as well?

function passArray(arr){
        var my_array = eval(arr);
...

   I rarely use eval, is there a real downside to this? Eval routinely
gets savaged.

Just know that you normally don't need it, so if you find yourself
using it, you are probably making a mistake.

This is server generated code and I would prefer not to
generate the array until below where the link is written. So if I did this:

(I think this is the right syntax)

onchange = "passArray("+some_array+")"

For what?

   Then it wouldn't be defined yet.

   Is there a better way to do this?

It isn't clear what you are trying to do.

 

[Lasse Reichstein Nielsen]

I have an event that I wish to pass a javascript array.

And I was thinking of using eval

That would be unnecessarily complex. I say that before seeing how
you will use it, confident that I will be right

onchange = "passArray('some_array')"

I assume "some_array" is the name of a variable holding an array.
Since you are prepared to use eval on it, I'll assume that it's
a javascript variable.

In that case, just do:
onchange="passArray(some_array);"
That will pass the array to the function.

function passArray(arr){
var my_array = eval(arr);
...
I rarely use eval, is there a real downside to this?

It's unnecessarily complex. That might not sound so bad, but it is.
It makes the code harder to implement, harder to maintain, and more
likely to break spontaneously.

Eval routinely gets savaged.

There are a few reasonable uses of eval, but they are all about
interpreting code received after the page was loaded (e.g., through XHR)
from trusted hosts (or that can be validated before running).

It's not something to use in normal programming. Ever.

This is server generated code and I would prefer not
to generate the array until below where the link is written. So if
I did this:

(I think this is the right syntax)

onchange = "passArray("+some_array+")"

It't not HTML syntax, so I doubt does what you want.

If you want to compute something in one place and use it in another, the
correct approach is to store it in a variable (although it will have to
be a global one) and refer to it by that variable's name. Just like any
other variable.

Then it wouldn't be defined yet.

It doesn't have to. It only needs to exist when the onchange event
handler is executed.

Is there a better way to do this?

Declare a variable, assign the array value to the variable, and refer
to it using that variable in the event handler.
This will only fail if the onchange event was somehow fired between
the even handler being attached and the array being defined.

You could even test for this:

... onchange="if (typeof arrayVar != 'undefined') passArray(arrayVar);"

/L

 

[Dr J R Stockton]

ECMA says that eval is only useful with a string argument. IMHO, unless
contrived, eval(Arr.toString()) is unlikely to be useful.

And eval(string) should only be needed if bracket notation is not the
answer, and the result of eval(string) cannot be predicted by the coder.


It is routinely used when the "programmer" perceives a need for a
computed identifier; bracket notation is the right way to do that.

There are a few reasonable uses of eval, but they are all about
interpreting code received after the page was loaded (e.g., through XHR)
from trusted hosts (or that can be validated before running).

I think not all : ISTM that you may be considering only
"commercial"-type pages, in which client-side processing may affect the
course of server-side events.

If the page server serves but nothing listens, then eval cannot harm
server processing of received data : the client-end person gets the
consequences of his input. I routinely use eval as a programmable
calculator, and to rough-test JavaScript code.