John Napiorkowski wrote:
A question about constant types. Duncan, you mentioned that the 'EqualsTo'
hint would basically be making the type a constant (although they wouldn't be
exactly usable as normal constants since they'd stringify to their type registry
name, not their value). I've done:
package MyApp::Constants;
use Sub::Exporter -setup => { exports => [ qw(NAME) ]};
use constant NAME=>'john';
...
package MyApp::Types;
use MyApp::Constants qw(NAME);
subtype AuthorName
as Str,
where {$_ eq NAME};
When I said 'constant', I was referring to the fact that any subtype defined
using 'EqualTo' would be defining a *singleton* type, a type consisting of
exactly one possible value, in which case any variable/attribute/etc declared to
be of that type is known to always hold that single value, and so referencing
that var/attr/etc is essentially referencing a constant.
I see limited uses for a singleton type definition in practice; probably its
main use is if you use it in defining a subtype of some composite type, such
that the subtype consists of all the parent type's values where a specific type
attribute is a single value. Although introspection is a good reason to have it
as well.
Mind you, you can do that with IsOneOf also, in which case EqualTo is just
another name for the IsOneOf case that takes a single element list.
Enough to consider if some tighter integration between types and constants
might be warranted. The above is fine in terms of separation of concerns, but
doesn't provide the type of meta data about the nature of the constraint to
anyone using it that I'd like to give.
Well sure, if you want to declare a singleton type for the sole purpose of
making introspection of the use of a single special value easier, go for it.
Duncan, I had a few questions specifically to your comments:
Precision
Scale
These have a problem of being, on the face of it, radix-specific. You
should generalize those into versions that also have radix parameters,
where 2 and 10 are likely the most common values; or maybe you already had
a radix parameter in mind.
So I added a Base hint for Num. The intended usage is something like:
subtype as Num[Base=>10, Precision=>xxx, Scale=>yyy]
With the goal of constraining a number. I lifted this from the SQL types. Let
me know if you think I am understanding your comment correctly.
Assuming that precision and scale are interpreted within the context of the
base, for example if you say [Base=>2,Precision=>31,Scale=>7] means a binary
number of up to 31 bits long with 7 after the radix point (or transpose
Precision and Scale if I mixed up the meanings of those terms), then yes you
understand me correctly.
-- Darren Duncan
