@rohit, the current behaviour wouldn't change at all. It would merely be introducing additional functional through new method (or otherwise by allowing Errors#add to take a block).
Tom On Thursday, 29 March 2012 02:21:59 UTC+10, rohit wrote: > > On Wednesday, March 28, 2012 8:54:36 AM UTC-5, Jason Rogers wrote: >> >> I don't like the idea of aliasing #count to #length. It's really not the >> same thing. I feel that the length method carries a connotation that count >> does not imply. Datasets are enumerable but they are not Arrays. They >> shouldn't be treated as Arrays. >> >> RE: the validation, I've no opinion. I don't tend to use the validations. >> >> On Tuesday, March 27, 2012 7:26:37 AM UTC-4, Tom Wardrop wrote: >>> >>> I just have a couple of suggestions for Sequel that I'd like to get some >>> community feedback on, hopefully getting a bit of weight behind them so >>> there's less debate over implementing these changes. >>> >>> 1) I believe #length should be added to Sequel::Dataset as an alias of >>> #count / #size? My rationale here is one of principle of least >>> surprise. Besides Sequel, I don't know of any other library that has an >>> objects that implements a length-like method but calls it something >>> different to every other Ruby library. I've been using Sequel for 6 months >>> now and still make the mistake of calling #length. While I respect the >>> argument that this helps force people to distinguish between an Array and a >>> Dataset, I don't think that ideal takes human nature into account. >>> >>> 2) While I like the simplicity of the validation implementation, I'd >>> like so see an alternate "smarter" interface. The problem I have at the >>> moment is that for a given field, I may have numerous validation checks. >>> Typically, if a field fails validation once, you don't want all the >>> validation that apply to that field to be run. I'll present an example >>> problem scenario below, and then demonstrate how it could be handled more >>> gracefully if Sequel had a smarter validation syntax. >>> >>> https://gist.github.com/2214994 >>> >>> There's a couple of advantages to the new syntax demonstrated in that >>> example. The first problem with current validation strategy is that if >>> :place_id is not present, the second validation will continue to run, >>> raising a method_missing exception as clearly if :place_id is not present, >>> then the :place association is going to be nil. These circumstances can >>> sometimes be hard to spot, and may not come pop up in testing for some >>> time. The second problem is that some validations could be expensive, so >>> you only want to validate data that hasn't already been deemed invalid. I >>> may not be checking the parent_id of the associated place, but may instead >>> be querying an external web service, as you may do if validating an entered >>> URL or the existence of a remote object. There's also a third advantage, >>> and that is that the new syntax is more concise. The condition is implied >>> (no need for "unless" keyword) an a block wraps better than a trailing >>> condition. You also get a private variable scope which you know what >>> conflict with any other variable that may be used for other validations. >>> >>> The implementation would be really simple. It's a matter of adding a new >>> method #validates (or even just allowing Sequel::Model::Errors#add to take >>> a block). This method checks the Errors hash to see if there are any errors >>> for the current field. If there isn't, the block is run. A return value >>> that resolves to true is considered a pass, a value that resolves to false >>> is considered a fail. >>> >>> Thoughts on those two suggestions? >>> >> > I also don't like the idea of aliasing #length to #count, mainly for the > reason Jeremy posted, #count is not idempotent. > > As far as validations, don't use them much so I don't have a strong > opinion. But would not like the current behavior to change since we do > report all failures to the user. > > Rohit > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/JYoNfJ8SmO0J. 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/sequel-talk?hl=en.
