Hi Tony, > Based on all the feedback, it is clear that there is not much consensus > around my idea. Before I give up, I have another suggestion: we could add an > option to create() and save() to specify how validation failures should be > handled. Specifically: > > :failure => :throw # throw exception on validation error > (save and create) > :failure => :return_nil # return nil on validation error (only > for create) > :failure => :return_resource # return resource instance on validation > error (only for create) > :failure => :nil # default behavior (save and create) > > In addition, there could be a way to change the default behavior for save > and create through DM config options. > > This could be through a plug-in or folded into the trunk. > > Thoughts?
I would certainly welcome and encourage anyone who wants to make changes to the public API to make it into a plugin first. I think real code has alot more value than theoretical changes, which has very little, if any. I say if you have *any* idea, write the code as a plugin and try it out for a while to see how you like it. I've been surprised many times by how a seemingly good idea didn't work at all in practice, and what I thought was a bad idea turned out to be awesome. One of the things we try to do with DM's API is make the code very "ruby-ish", sticking with common idioms and conventions that (appear to be) more widely used in the Ruby community. We try to make it so that someone who is used to using PORO (plain old ruby objects) can pick up and understand DM. For example, note how we store attributes as ivars, so if you have an :email property it will store the value in @email by default. Also take how we do Collections, where we've gone to great lengths to make Collection behavior identical to Array, even thought underneath the entries are not loaded until a "kicker" method is called, like #to_a or #each. Keeping the DM API clean and easy to use is my #1 priority. We still have a few conventions borrowed from other ORMs that we review regularly and try to find better alternatives. As you mentioned earlier in the thread, the Resouce#new_record? is a bit ugly, and will probably be deprecated in favor of Resource#new? and Resource#saved?, with the latter mostly to help clean up the presence of somewhat ugly conditional syntax: I'd much rather write "if user.saved?" and "if user.new?" than "if !user.new_record?" and "if user.new_record?". With that said, I've never seen an API in a popular ruby library where throwing exceptions vs. return values was configured based on the arguments provided. I'm not entirely convinced that as a solution it will be any cleaner than what we have now. Please though, try to prove me wrong with actual code :) Dan (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
