> 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).
OK, so from my perspective the ideal solution would be that you can
just tell your users to require the json gem *after* activesupport,
and have everything 'just work' because it nukes our methods. If
that's not the case, lets fix it.
> 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...
Our current json implementation works fine for my projects, if there
are bugs we should fix them. But 'just rewrite it' is generally a
great way to break stuff and piss people off.
> 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.
> Kenneth Kalmer