Agreed, all this is possible with the "block" approach (though I don't think it's any more standard than a "method" approach.) It smells bad to me though.
The responsibility of the model/dataset is to use things in its domain (associations, attributes, etc.) to turn itself into a data structure that's appropriate for serialization to JSON. The actually turning-it-into-a-string part should is the responsibility of the data structure or JSON lib, and shouldn't be tightly coupled to the model. I'm not saying that to_json shouldn't return a string (it should, obviously), or that you should do whatever ActiveSupport does (gross), just that getting the intermediate representation should be considered a primary use-case. By pretty-print I meant using pretty_generate or something - I don't think this is possible with Sequel right now except globally. > On Jun 11, 2017, at 08:21 AM, Jeremy Evans <[email protected]> wrote: > > On Sunday, June 11, 2017 at 7:55:46 AM UTC-7, Daniel Leavitt wrote: > Any particular reason you were thinking of solving this by having to_json > accept a block? It seems to me like having a method that returns an > intermediate representation (like as_json in ActiveSupport) is a more > flexible approach. > > For instance, let's say your model has a summary representation, a standard > representation, and a full representation that each depend on the prior. It's > cleaner for them to be able to call each other instead of having to forward > blocks. Ditto for inheritance, if your model mixes in or inherits a base > serializer. There are also plenty of scenarios where you're not interested in > the string at all - maybe you want to pretty print or serialize to bjson or > put it in queue or DB or something. The to_json block approach still couples > the intermediate representation to the string representation, so it's going > to be clumsy if you're primarily interested in the former. > > Thoughts? Would you be open to a PR along these lines? > > My main issue with this is that as_json isn't standard. If you can get the > ruby json library to support as_json and have to_json call as_json if as_json > is defined, then I'll switch Sequel to that. > > The argument about calling to_json but not wanting JSON (for pretty printing, > etc.) falls flat with me. If you want a generic method that serializes to a > hash, it probably shouldn't have json in the name. > > FWIW, I've already shown how as_json can be implemented by the proposed > to_json by returning from the block passed to to_json, so if you want to use > as_json (for pretty printing, etc.), it's trivial to implement yourself. In > general, using a block is the more flexible approach, as it gives the user > more control. > > Thanks, > Jeremy > > -- > You received this message because you are subscribed to a topic in the Google > Groups "sequel-talk" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sequel-talk/FOQ_09mizKw/unsubscribe > <https://groups.google.com/d/topic/sequel-talk/FOQ_09mizKw/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/sequel-talk > <https://groups.google.com/group/sequel-talk>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
