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? > -- 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/-/SKzt_-0Hq_AJ. 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.
