5 ms·

That first example is a little silly. Rails validations have little to do with instantiating objects and are mainly concerned with preventing persisted invalid

That first example is a little silly. Rails validations have little to do with instantiating objects and are mainly concerned with preventing persisted invalid state (why they are designed to run before calling "save"). This is incredibly useful as a safeguard against persisting bad data, which is much more harmful than simply instantiating an object with bad data. Validating objects during instantiation sounds great, but it isn't really the purpose of ActiveRecord's validations. That said, the second example is very cool/interesting. Anything that makes type more explicit in Ruby is a move in the right direction.

benmmurphy 11y ago
the second example misses what is most important about Rails validations which is spitting errors (plural is important) out for a form. by using an exception which goes off when a field assignment is not valid it is restricted to only giving back a single error.
- jeremiep 11y ago
  To me the article was more about the anti-pattern of having self-validating objects than trying to show where it can end badly. I now use only plain data (scalars, sequences and mappings) to represent data. The validation can be implemented independently and I can reuse all of the language's data manipulation functions. Its really the best of both worlds. As Rich Hickey said in "Simple Made Easy", the only thing you can do with data is destroy it by encapsulating it.
- solnic 11y ago
  dry-validation supports typical validation behavior known from rails where errors are gathered and represented in a string representation. In fact it's much "smarter" than AR validations as it only executes validation functions that are needed and fill in other potential error messages based on rule definitions. This is one of the reasons why it's multiple times faster than AR validations and more extendible. With dry-data constrained types it's a different story. It raises type errors because we're dealing with lower level objects of your system. Personally I prefer to see a meaningful type error rather than exceptions like "foo called on nil" etc. Not to mention that constrained types increases the chance of spotting type-related bugs earlier.
- emergentcypher 11y ago
  Why not throw an exception containing a list of invalid field errors instead of just one? That would only work in the constructor though not if you're setting fields individually.
ubernostrum 11y ago
Also, deliberately instantiating "partial" objects is at times a useful optimization, and can save processing time and/or memory.
- solnic 11y ago
  Of course it is and I would never question that. The problem we're dealing with here is that you're using same type of objects for optimization purposes.
solnic 11y ago
It is silly when you look at it from the AR perspective, but if you look at it from a more general pov, it pretty much means that you have a single object that can be in many different states and what a given object really is, becomes ambiguous. I understand why it works like that, in fact, I also understand how it's valuable - it is a simplification, a shortcut, a convenient way to work with the data by providing lots of dynamic interfaces. There is a downside though - it is not helping in building more complex and robust systems. At least from my experience.

benmmurphy 11y ago

the second example misses what is most important about Rails validations which is spitting errors (plural is important) out for a form. by using an exception which goes off when a field assignment is not valid it is restricted to only giving back a single error.

jeremiep 11y ago
To me the article was more about the anti-pattern of having self-validating objects than trying to show where it can end badly. I now use only plain data (scalars, sequences and mappings) to represent data. The validation can be implemented independently and I can reuse all of the language's data manipulation functions. Its really the best of both worlds. As Rich Hickey said in "Simple Made Easy", the only thing you can do with data is destroy it by encapsulating it.
solnic 11y ago
dry-validation supports typical validation behavior known from rails where errors are gathered and represented in a string representation. In fact it's much "smarter" than AR validations as it only executes validation functions that are needed and fill in other potential error messages based on rule definitions. This is one of the reasons why it's multiple times faster than AR validations and more extendible. With dry-data constrained types it's a different story. It raises type errors because we're dealing with lower level objects of your system. Personally I prefer to see a meaningful type error rather than exceptions like "foo called on nil" etc. Not to mention that constrained types increases the chance of spotting type-related bugs earlier.
emergentcypher 11y ago
Why not throw an exception containing a list of invalid field errors instead of just one? That would only work in the constructor though not if you're setting fields individually.

ubernostrum 11y ago

Also, deliberately instantiating "partial" objects is at times a useful optimization, and can save processing time and/or memory.

solnic 11y ago
Of course it is and I would never question that. The problem we're dealing with here is that you're using same type of objects for optimization purposes.

solnic 11y ago

It is silly when you look at it from the AR perspective, but if you look at it from a more general pov, it pretty much means that you have a single object that can be in many different states and what a given object really is, becomes ambiguous. I understand why it works like that, in fact, I also understand how it's valuable - it is a simplification, a shortcut, a convenient way to work with the data by providing lots of dynamic interfaces. There is a downside though - it is not helping in building more complex and robust systems. At least from my experience.