You're a star, this is pretty close to what I'm after.

There are reasons why I am using Tangram over, say, Class::DBI:

• Support for Polymorphism in data types
• Support for non-trivial relationships between classes (sets, arrays, etc)
• Objects that contain/refer to other objects are automatically loaded as needed via a tied variable
• Queries are in Perl, not SQL. This is achieved with a very clever trick - having a variable type that represents a "remote" (that is, not local) object, and overloading functions on that so you can do, eg $db->select($remote_orange, $remote_orange->{field} eq "value");. This returns a data structure that can be converted by the object data persistence engine to a SQL query.

What I think is the direction from here is to refine Class::Contract to the point where it is suitable for generating storage schemas; be they Tangram or Class::DBI or Alzabo or whatever. "Scalar" is, by definition, of boundless length, which isn't too useful if you want to store it in a column of a relational database.

Thanks for the pointer, I guess I'll take up this conversation with the Class::* maintainers. The POOP list, which seemed the natural place for this, seemed worryingly quiet.

srand 3.14159; print join("",
sort{rand 1<0.5}map{$_^"\037"}split m{
}x,"qmptk|z~wOzm??l]pUqx^k?j"),",\n";
[download]