troels knak-nielsen wrote: > On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar <sc...@macvicar.net> wrote: >> For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE >> parameter to the options flag. So you can use >> >> json_encode($var, JSON_STRICT_ENCODE); >> > > I'm really not a fan of named constants to change the semantics of a > function like that. Not to mention that it's a pita to type out, so > nobody would bother. It also doesn't address the crux of the matter - > That the name json_encode is slightly misleading, in that it may or > may not emit json. > > Would it be a problem to introduce a second function (js_encode?) > instead? It could work as json_encode does today, and json_encode > could then be changed to raise a warning on illegal input. I realise > that this means breaking existing scripts, but it's a trivial change, > and if it's announced in advance, people should have time to make that > sed -r '/json_encode/js_encode/g' to their code base. >
We already have PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP and PHP_JSON_HEX_APOS as options for json_encode, this would just be adding another bitmask. In the future if need be we can make it the default value so it raises a warning. I have no interest in doing a js_encode functions as it opens us up to implementing a lot more functionality. The appealing this about json is that its a subset of JavaScript. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
