If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

1. despite the chicken-little style warnings, i've never seen an attack using eval on a supposed data source. people use google CDN scripts all the time, even from https. The fact that most people use JSON.parse likely means an attack requiring eval has a limited vector and a huge failure footprint.

2. the charts on performance seem to indicate that it's roughly 2-3X faster to use parse instead of eval. But, since it's typically a one-time operation, 1mb data /sec is not really noticeably faster than 400kb /sec.
aside from that, you are advocating a user-land JSON.parse() and if you compare that to eval(), eval() beats the pants off of a json2.js-style add-on.

i'm not saying don't use parse, i'm just saying that the reasons for not using eval() are not terribly compelling.

Still, it's better to use Function("return "+strJSON)() instead of eval as its faster and safer.

you can do something like this for a more secure "poor man's parser" where JSON is not built-in (ala IE7, ASP, JSC.exe, etc):

But if you are expecting a JSON format in the ajax responseText, then you would naturally make sure that a valid JSON object is returned. If you use eval, then any JS expression could be returned and evaluated and your code will fail even if eval returns no error (valid JS expression) if invalid JSON is returned.

I would never do that in production code. I just did it for a quick and dirty test. Just to make sure his JSON was indeed legal. Tell you the truth, I didn't know the IE9 had JSON built in and that happened to be the browser I had open at the time. I later discovered that works in IE9. But I don't think it works in IE8? Or is it just IE7?

I do not fully understand why Javascript is unable to loop through the JSON object as if it were an array, especially when the top-dimension variables / keys are numbers (ie easily sortable). Can anyone elaborate on this in layman's terms?

Okay. In simplest possible terms:

An array is an array. An object with property values is not an array.

Just because we can use the same notation to access array elements as we can to access object properties does not make them the same. Heck, we use a period between the integer and fractional parts of a number, but that doesn't make the number 3.1415 the same as an object.property reference. Similar syntax does not necessarily denote similar underlying capabilities.

Perhaps we could also point out that you can't give numbers to array elements as part of the expression on the right hand side of the assignment (=) operator.

That is, you must code

Code:

whatever[3] = "something";

never

Code:

whatever = [3,"something"];

or anything similar.

There's a *HUGE* difference between

Code:

whatever = [3,"something"];
and
whatever = { 3 : "something" };

The former creates an array of two elements: whatever[0]==3, whatever[1]=="something".
The latter creates an object with one property: whatever["3"]=="something".

Notice that I coded ["3"] there and not [3]. Actually, whatever[3] would have worked, but of course it's very misleading in appearance. It's just another case of JS silently converting a number to a string for you.

Which is one reason that I avoid using object property names that look like numbers or even that start with digits.

For one thing, if you do

Code:

whatever = { "p3" : "something" };

Then you can code alert( whatever.p3 )

Whereas if you do

Code:

whatever = { "3" : "something" };

Then KABLOOEY if you try to code alert( whatever.3 )

So although your use of numbers-as-strings for the top-level property names in your JSON object works, it's not something I would ever do. If nothing else, I would give them a prefix (e.g., "item0" : {.... } ).