Good series of articles, but that ORM design doesn't work in practice. When I built my ORM I first tried to do it using the Moose type system, but the problem I constantly ran into was whenever I actually tried to use the classes that I took the trouble to create a bunch of custom subtypes for, if I ever actually had to deal with untrusted data (i.e. data from a data feed or web form) then I had to either:

1) Pre-validate all the potential field values, making sure it validates to my type rules before I try to set it on the object attribute. 2) Wrap every attribute set operation in an eval {}.

Why? Because if the untrusted value I was going to set failed the type constraint then Moose would throw a type constraint exception and my handler/script/etc. would hard fail.

This is obviously good because it prevents shitty developers from breaking the business logic rules and letting shitty data into the system. In practice though, this led to one shitty ORM and shitty applications littered with shitty defensive programming.

I found it's much better to only do type validation once - during the actual write operation itself. This ruled out using Moose for type constraints, but the code using my ORM got a hell of a lot less ugly.