If I had sufficient time and patience to write the patch and argue about it on the Perl 5 Porters mailing list, how would I implement optional types for Perl 5?
(Dave Rolsky gets it right in the comments: this has to be part of the core to canonize the names of the roles the Perl 5 primitives provide. This idea is worthless when more than one CPAN implementation exists, if they diverge on naming conventions — and, for all I like the CPAN, divergence is inevitable.)
If I had my way, I'd add a new keyword and op combination. I like does. (In my imaginary fantasy world, I win all arguments through the unassailable forces of logic and good taste alone. Also I have a hovercraft.) I'd also add a table to store the behaviors that builtins support. That is, a hash always does Hashlike and a hash reference always does Reference and Hashreflike. Similarly, a regex does Stringifies (or Stringlike).
It's important to leave bikesheds so people on p5p have something to argue about other than the implementation.
I'd also add a storage location within classes to keep track of all of the roles class instances perform. This is necessary because....
... tie and overload have to update that does list depending on the behaviors they support.
does might end up performing separate operations in boolean
(scalar) and void context. In boolean context, it returns true if the first
argument performs the appropriate roles. In void context, it marks the current
class as performing the appropriate roles. (This is nice if Perl 5 ever gets a
class keyword; it falls out as nicely as the syntax for MooseX::Declare.)
The method form is already available thanks to UNIVERSAL::DOES.
Those two forms can tie together nicely.
This produces allomorphism for objects (or classes or anything which supports method invocation) as well as non-invocants (Perl 5 primitives).
The remaining question is what to do with ref(), which doesn't work and tends to break code.
...
... and there, my mythical patch removes ref(). Forget backwards compatibility. Sometimes writing correct code in the present and future means removing the ability to write incorrect code and requiring people to fix broken code in the present.
The nice part about this imaginary patch (besides having neither to write it nor argue for it) is that it's perfectly compatible with further imaginary patches to add function signatures to Perl 5 -- with type checking, of course -- and a class syntax and even multidispatch. All of those features are perfectly optional.
Of course, ref() could stay in that world. The possibility
exists that the temptation to use shiny new features which remove boilerplate,
work more correctly, provide better abstraction possibilities, and simplify the
design and implementation of code would encourage people to adopt better
programming practices and remove dangerous, ugly, ill-designed, and confusing
practices from their code. Sometimes that even works.
(These features all work in Perl 6 today. Try Rakudo now.)
