Toby's Random Thought #3 - API for dealing with types

[tobyink]

Types would need to be first-class for this, but it would be good to have an API to export types to whatever lexical scope is currently being compiled, like export_lexically in blead's builtin.pm.

Data::Checks->export_lexically( 'UINT', as => 'Count' );

It would also be good to be able to declare types via an API. Something like:

Data::Checks->declare_type( 'PositiveInt', isa => 'UINT', where => sub ($n) { $n > 0 } );

[Ovid]

The docs in Data::Checks::Parser are extensive, so it's hard to wade through them. See "Check Inheritance":

check PosInt  :isa(INT)  ($value)  { $value > 0 }

[Ovid]

Also, we don't need to export checks. We just need a central registry. With that, when the system encounters :of(...) or :returns(...), it consults the type registry to determine if the type exists. That makes the system much easier to use.

[Ovid]

Oh, and the central registry also makes it harder for duplicate type names to be used.

[tobyink]

A central registry is not a great idea. What happens when one CPAN module defines NaturalNumber to be a positive integer and another defines it as a non-negative integer?

[Ovid]

Sorry, I wrote that far too quickly.

I mean a central registry per project. Unfortunately, Perl doesn't have the concept of a "project" the way so many other modern languages do (I've griped about this a few times, but don't have a clear vision). You have the types for your project and if you use another project, you could explicitly import those types, along with aliasing/excluding/renaming, just like roles. What I don't want is this (borrowed from client code):

use Our::Types qw(
  ArrayRef
  Bool
  HashRef
  DbTable
  DbFields
  Optional
  Str
  Undef
);

I'm constantly curating those, adding new type names and deleting unused ones. It's grunt work that takes away from time doing real work for my client.

[tobyink]

The docs in Data::Checks::Parser are extensive, so it's hard to wade through them. See "Check Inheritance":

check PosInt  :isa(INT)  ($value)  { $value > 0 }

No, I saw that. I'm talking about metaprogramming without having to use stringy eval to define types.

[Ovid]

Ah, yes. I see that now. My bad.

I love metaprogramming and I think it would be good. My main concern is that checks are currently declared at compile-time, while metaprogramming is usually done at runtime, too late to affect checks.

Can you give some examples? (e.g., dynamically building an ENUM from a database enum, for example)

[Ovid]

It occurs to me that the check syntax is evaluated at compile-time, but the check itself doesn't occur until runtime. So there's wiggle room here.

[tobyink]

From the point of view of an exporter, it's exporting things at runtime. But from the point of view of the module importing the things, it's happening at compile time.

I want an API that I can use to define types at my run time, for other modules to import at their compile time.