Re: #to_json incompatibilities between ActiveSupport & JSON gems

Kenneth Kalmer
2008-11-29T12:46:43Z

On Sat, Nov 29, 2008 at 2:30 PM, Michael Koziarski
<michael@koziarski.com>wrote:

>
> > Any thoughts on this? I added a simple fix to ruote
> > (http://tinyurl.com/6boobf) for Time#to_json and it works perfectly. I
> just
> > can''t help but think more and more people would use
ActiveSupport outside
> of
> > Rails, and especially in an environment where the JSON gem is
present...
>
> I''m a little hesitant because those arguments to to_json are just
> ignored.  So you get ''compatibility'' in the sense that
you don''t get
> an ArgumentError, but it won''t do what you think it will.
>
> Silent misbehaviour here seems *worse* than failing fast?


Agreed. For my example above it works perfectly well, since I''m not
really
concerned with the Time instances. They''re just part of a JSON payload,
and
I control only part of the payload (where time doesn''t matter).

How about this? (Don''t kill me if I''ve stepped out of line
here). When the
JSON gem(s) are present and loaded prior to ActiveSupport, ActiveSupport
backs off from re-defining all the #to_json methods and delegate the
decoding work to JSON again. Another obvious thing would be to load
ActiveSupport before JSON and have JSON simply overwrite the work of
ActiveSupport. Another option might be to strip down json_pure and bundle it
into ActiveSupport, seeing my local copy is roughly 756KB...

But the co-existance of the JSON and ActiveSupport gems in the same projects
cannot be ignored. The ruote project, and other fast moving targets like
CouchDB will make this an increasingly bigger issue in the future.

I honestly don''t know what the impact of any of these would be.
I''ll keep on
throwing ideas at the list, even if it is all the wrong ones, just to keep
the thoughts churning and get us closer to a solution.

Anycase, thanks for your patience.