$.evalJSON and $.toJSON are already assigned to JSON.parse and JSON.stringify if present so I think it makes more sense to leave as/is and not impose a new dependency on users when the upgrade. WDYT?

Strangers input: I had to include JSON2 because of weird parsing behaviors
between phones. Would be nice if it was included. It's not a dependency if
it provides interoperability IMO.

On Sunday, March 3, 2013, David Chelimsky wrote:

$.evalJSON and $.toJSON are already assigned to JSON.parse and
JSON.stringify if present so I think it makes more sense to leave as/is
and not impose a new dependency on users when the upgrade. WDYT?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-14358113
.

$.evalJSON and $.toJSON are already assigned to JSON.parse and JSON.stringify if present

what are they assigned by? jquery-json?

I guess it just feels less risky to me to have the websocket library using either the native apis or polyfill implementations of them. I don't have anything against jquery-json. this just doesn't seem like a class of functionality that needs a jQuery facade.

@bcm yes - in jquery-json. So if it's already supported by the browser's JS engine, you get that definition. If not, but you include json2 before jquery-websocket, then you'll get json2's defs, which will pass through to the native implementation if present. So you can have this rely on json2 if you choose, but in order for jquery-websocket to rely on json2, we'd force end users to require json2 before jquery-websocket.

@bcm re: the jquery facade, my suspicion is that's just legacy - i.e. jquery introduced these functions before their other-named-counterparts became standard (and before json2 came to be), so keeping the names as/is is a legacy issue in jquery. Perhaps the best solution here is for jquery-json to def JSON.parse and JSON.stringify as polyfills, degrading to its current implementations of $.evalJSON and $.toJSON. We end up w/ pretty much the current scenario in terms of the code that runs, but at least the APIs match the native APIs. WDYT?

@justadropofwater appreciate the issue, but not sure how to solve it from jquery-websocket (per my comments to @bcm). For me (and I think for most), a dependency is not a matter of what it provides, but a matter of module A needing module B in order to work.

even if jquery-json were to define JSON.parse and JSON.stringify, one would still be forced to require jquery-json before requiring jquery-websocket because the latter expects $.evalJSON and $.toJSON to be defined. so the developer still has to discover the existence of that external library and go to the effort of integrating into his application.

if jquery-websocket instead called JSON.parse and JSON.stringify, then the user could either 1) require json2 before jquery-websocket, 2) require a version of jquery-json which defines those symbols before jquery-websocket, or 3) direct the user to use a browser which supports them natively.

seems like the latter strategy is a little less surprising, gives the developer more choice in the matter and anticipates a world in which all browsers in use support the standard methods natively.

or am I still missing something obvious? 🐐

@bcm I hadn't considered the fact that we're already requiring jquery-json for this. I'm convinced this is a good direction now.

The one risk here is that a developer upgrades without understanding this change, views in a browser that already supports JSON.parse and JSON.stringify so sees no issue, deploys and now the app doesn't work in browsers that don't support these functions. Thoughts about that?

@bcm oh - by "direct the user to use a browser which supports them natively" you were covering that case. I'm not sure that's an acceptable outcome for all developers, but it might be the best option. Wanna submit a PR that does that?