Mark Wood-Patrick wrote: > I would like to add my own parameterized type e.g. I would like to be > able to create types like: Parameterized types are about looking at a value on its own and seeing if it qualifies as a member of the type, not about context of usage. > SzStr[32] > > Which would allow me to specify the maximum size of a string that an > attribute can have and will validate the size of the data I’m storing in > the attribute That one makes clear sense. > Or to specify that an attribute is a secondary key in some DB like: > > DBKey[User] > > Where User is a Moose class that provides an in memory version of a DB > record and the attribute would be a weak reference to such an object This example is ambiguous as to what you meant, and only some resolutions of that ambiguity make sense. 1. In a relational database, a key is a property of an entire table, or of a rowset, and not of an individual record. A set of attributes/columns is a key in a rowset or table if every record has unique values there. It doesn't make sense to look at an individual record and ask whether certain attributes/columns are keys because you don't have the context in which to judge it. Or, in a trivial sense, where you look at a record as a rowset of a single row, every column is trivially unique and a key therein. So in that case, your DBKey[User] would not be a constraint for a record object but rather for a recordset object. Similar to if you had a UniqueArray Moose constraint that said the value is an array whose values are all unique. 2. Now, if instead your record object has meta-data that says particular attributes/columns have key constraints in their database tables, then that makes more sense to be a Moose constraint insofar that you are just asking whether an attribute exists in a record marked with metadata saying it corresponds to a key column. 3. If you are wanting your constraint in the second case to go further and check that your key attribute is unique against an external database, I don't think that this is what type constraints are for, parameterized or otherwise, and trying to use them that way is a design or conceptualization flaw. Type constraints are supposed to be deterministic and not depend on variables (such as a mutable database) to determine whether they pass or not. Another example of misusing a type constraint is having a constraint that says "this datestamp is within 3 seconds of the current systemtime". I think it would help clear things up if you provided more details or clarified what you actually wanted the DBKey[User] example to achieve. -- Darren DuncanThread Previous | Thread Next