4 ms·

Ignoring what pilif said (which is all valid), the problem with accepting any of <identifier> <identifier>.<identifier> <identifier>[<integer>] is that

Ignoring what pilif said (which is all valid), the problem with accepting any of <identifier> <identifier>.<identifier> <identifier>[<integer>] is that the choice of just these three is kind of arbitrary. Really, you're whitelisting a specific subset of "expression" that presumably returns a function to be called. Why not allow a function that returns a function? Or an object property references as object[string]? Or nested object.property.property expressions, or an arbitrarily complex expression? It's much easier, if you're going to actually limit it, to just accept a single string and have the calling page be sane enough to make sure that name is in scope and resolves to a callable function, rather than making the whole thing harder on yourself trying to figure out exactly which expressions are "safe(st)".

tav 17y ago
If I understand it right, you're suggesting limiting it to just an <identifier> ? I agree and if we would all standardise on just that it'd fine by me... But, having said that, array_of_functions[index] is also a common pattern that i've personally had to resort to several times... and is also defined in the original JSON-P article... The code already supports nested object.property.property expressions and I'd welcome patches to support object['key'] -- which I've also used several times in the past. And given the very little extra effort (less than 10 lines of code) required to support: <identifier>.<identifier> <identifier>[<integer>] I didn't see why/how it'd hurt to put that forward to standardise around... ?
- thwarted 17y ago
  Because it's (relatively) easy to validate (if you're going to) a simple identifier (ignoring UTF-8 issues and that $ can be in an identifer, I'd almost consider it matching ^\w+$ to be enough), and it's increasingly harder to properly validate javascript expressions without actually having a javascript interpreter and parsing/executing it. More complexity means an incrase in the possibility of bugs and more divergent implementations.

tav 17y ago

If I understand it right, you're suggesting limiting it to just an <identifier> ? I agree and if we would all standardise on just that it'd fine by me... But, having said that, array_of_functions[index] is also a common pattern that i've personally had to resort to several times... and is also defined in the original JSON-P article... The code already supports nested object.property.property expressions and I'd welcome patches to support object['key'] -- which I've also used several times in the past. And given the very little extra effort (less than 10 lines of code) required to support: <identifier>.<identifier> <identifier>[<integer>] I didn't see why/how it'd hurt to put that forward to standardise around... ?

thwarted 17y ago
Because it's (relatively) easy to validate (if you're going to) a simple identifier (ignoring UTF-8 issues and that $ can be in an identifer, I'd almost consider it matching ^\w+$ to be enough), and it's increasingly harder to properly validate javascript expressions without actually having a javascript interpreter and parsing/executing it. More complexity means an incrase in the possibility of bugs and more divergent implementations.