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 Duncan
