Now that we've gone through the trouble of making MooseX::TypeLibrary work
correctly with parameterized types, along with the needed modifications to
Moose (a lot of this still in repo, but working nonetheless) I was thinking we
could use this to create some enhanced versions of our core constraints. What
I am thinking about is adding more declarative abilities to our core
constraints, for example:
Str[MaxLength=>10]
which would do something similar to:
subtype MaxStr10, as Str, where { length $_ <= 10 }
I know I've done the above more than once, and I am sure I am not alone.
Besides saving time and improving readability, there would be a lot of benefits
to moving more information into introspectable meta data, which could be used
in novel ways.
I think it would be ideal if we could cook up the most common constraint needs
and build them into this system in a way that would be introspect able, that
way they would play nice with systems like Ernst and Reaction which use
attribute derived meta data to infer all sorts of neat things. Also, for my
own needs, I'd like to see something here that would play nice with ORMS like a
future Moose version of DBIC, that way we could deploy tables and such from the
data introspected from the constraints and attributes.
My hope here is to create something that would cover a high percentage of our
normal constraint needs while offering usable meta data to systems like
Reaction, Ernst, future DBICs, etc. For me, I see this as a final constraint
layer before information is sent off to Storage or used by my business logic.
Although I am a web applications programmer, I don't really see this as
something that sits in the role of form input validation, although it could be
a basic layer upon which something like that is built (again I am thinking
integration with Reaction and Ernst). Because of that you will see I've models
constraint options against SQL/XML Schema types as well as a few of the more
common form validation types.
Given that I am asking for your thoughts and input as to how what options we
want here. In particular I hope to hear from some of the people responsible
for the named projects (Reaction, Ernst, DBIC), since I am hoping to provide
something useful to you.
These new constraints would be built on top of the to be version of
MooseX::TypeLibrary. Here's beginning list of options and their constraints,
but please lets all think about how this could be done right. I can see from
looking around CPAN there's probably a dozen constraint oriented systems and
I'm hoping to cherry pick code from all the best ideas out there.
Additionally, since our type constraints are arranged in a hierarchy, my
intention is that the options would be inheritable. Also, I added a few new
core types. I realize there may be some overlap, but I wanted to put all the
ideas down (like 'OneOf' probably overlaps with Enum) Lastly, I am thinking it
might be a good idea to have official aliases for many of the possible longer
option names. Hopefully the names I'm choosing are self explanatory, but once
we all start to nail down the spec I'm add more details.
Item[
Default
]
Bool
Maybe[`a]
Undef
Defined
Value[
IsOneOf||Enum
]
Num[
LessThanOrEqual || '<='
LessThan || '<'
GreaterThanOrEqual || '>='
GreaterThan || '>'
EqualTo || '='
Precision
Scale
]
Int[
Signed
UnSigned
]
SmallInt
BigInt
Str[
ASCII
Printable
Word (must be a single 'word')
MaxLength
MinLength
EqualTo || 'eq'
]
ClassName[
PackageBase (For stuff like '::Plugin::MyPlugin')
]
Ref
ScalarRef
ArrayRef[`a][
MaxElements
MinElements
]
HashRef[`a][
HasAllKeys
]
CodeRef
RegexpRef
GlobRef
FileHandle
Object[
HasMethods
ISA
]
Role[
Requires
Does
]
This is just my first shot and there is obviously room for improvement, but I
would like to kick off the conversation. So what is missing? Do we want to
add more types, like for URIs, or fixed types like ZERO, INFINITY, etc.
Declare-Constraints-Simple has some neat features for aggregating constraints
(And, Or, Not, Xor, ect.) We have Union, which covers Or, but maybe we'd like
more. Is there stuff here you think doesn't belong? Does it belong in a
separate project, or just doesn't belong period? What other existing type
constraints libraries might benefit from this approach? For example, I've done
a bit of work on MooseX::Types::DateTime[X] and was thinking this could be used
to hint stuff like TimeZone information (ie isa=>DateTime[TZ=>'USA/Eastern']
and similar).
I know this is a lot to review, but I should be on IRC often for discussion.
Sincerely,
John Napiorkowski
