Mysterious design decision in Hash#to_json

rubyonrails-core
1

Hi guys,

Hoping to learn something here. (folks at #8762 would be interested as well)

Currently Hash#to_json produces text with unquoted keys, which is invalid JSON. Asking developers to set ActiveSupport:: JSON.unquote_hash_key_identifiers to false if they want valid JSON doesn’t seem in character of Rails, i.e. “smart defaults”… or is valid JSON the rarer requirement in common cases?

This doesn’t appear to be a bug nor an accident. In fact, thought and effort has gone into making to_json to consistently produce invalid JSON: [ 5486], [6443]. i.e. [6443] fights away ticket #7714 by bringing in an elaborate ActiveSupport::JSON::RESERVED_WORDS instead of returning to produce valid JSON (as requested in ticket).

Hope somebody could shed some light on this design decision and I’ll learn some Ruby.

Cheers

2

Didn’t even know Rails did that. Since #to_json produces valid JavaScript, obviously we that are using JSON from Rails didn’t realize that in fact it isn’t valid JSON.

There isn’t any explanation to unquote the hash keys except to save a few bytes, which is hardly worth invalidating the spec. After all, JSON data is used in far more places than just eval() in JavaScript.

3

aloha,

From schema_statements.rb:

    def options_include_default?(options)

      options.include?(:default) && !(options[:null] ==

false && options[:default].nil?)

    end

Isn’t that the same as simply:

    def options_include_default?(options)

      options.include?(:default)

    end

?

lawrence

4

No. The first one checks if the options[:default] is not nil when options[:null] is false. The second only checks for the presence of :default as key, which is far from equivalent.

5

I want to know why too, and I think we should get an answer soon considering how DHH seems to want to achieve feature parity between JSON and XML for Rails 2.0 (you can, for example, use ARes while speaking JSON and AR objects now convert nicely to JSON).

I agree it just doesn't make much sense to me either to have invalid JSON emitted by default.

Cheers, Chu Yeow

Mislav Marohni�? wrote:

6

Currently Hash#to_json produces text with unquoted keys, which is invalid JSON. Asking developers to set ActiveSupport:: JSON.unquote_hash_key_identifiers to false if they want valid JSON doesn't seem in character of Rails, i.e. "smart defaults"... or is valid JSON the rarer requirement in common cases?

I've dug around the history and asked a few folks an it seems there's no particularly valid reason for us to continue to support the current behaviour. Send in a patch which switches the default and perhaps removes the option, and I'll see it gets applied.

7

Maybe the option should stay but have no effect and should trigger a deprecation warning?

8

Awesome. Thanks for digging around!

I've submitted a patch here: http://dev.rubyonrails.org/ticket/8762 (please ignore the first patch, that's the wrong file).

Please take a look.

Cheers, Chu Yeow

Michael Koziarski wrote:

9

+1 and patching test in actionpack as well

Looks like this is rolling along :slight_smile:

10

Applied.

11

Thanks!

12

DHH wrote:

Applied.

Awesome. Valid JSON at last :slight_smile: Thanks Choon Keat, Michael and DHH for making this happen!

13

Thank you again!