Programming with Moose/Problems solved/Type-system

Perl lacks and Moose doesn't. At least, not nearly as much. Back to the issues of Perl, more specifically another feature not covered by the Object System but delivered as a blessed benediction of Moose. So in this example, you're writing a program and like a good programmer, *all* of your URLs are handled by  objects, and all of your methods operate on   objects - or at least they think they do. Having methods dependent on  objects is a good thing. Trust me, it is, the alternative is heaven-1. Unfortunately, when you publish the module to a world of intellectually inferior blokes you have no streamlined method of making sure they send only URIs.

Again this is where Perl is lacking. All urls are stored as  objects, but you can't easily make sure they're only   objects.

Roots in pre-object fanaticsm
Ponder for a bit the utility of sigils. One of the side effects of sigils is a function knows at compile time whether or not the input sent to it is in the right ballpark. Perl's sigils are a little more voodoolicious because sometimes they can change the value by acting as an operator. Let's look at how perl deals with validating input.

In the following example, the class HashOperations expects a HashObject:

So the issue here, is that the procedural non-referenced form will be caught in compile time, and all other object variants will not.

The old way
The old stock-Perl way to tackle this problem was really a joke on the users. Rather than adding specific functionality to the CORE, or radically modifying it, the core-team would rather bother the programmer with modular language add-ons that productivity is totally dependent on. We can speculate on the reasoning for the lack of TypeConstraint functionality.


 * There weren't any examples of interpreted languages for Perl to model itself after, never mind interpreted languages with base-object types.
 * Perl's references came before its objects.
 * A hash is a Hash (of Scalars), an array is an Array (of Scalars). A good portion of this can be determined on compile time by the use of perl's sigils. This is not so with Objects which occur wholly at runtime, and aren't granted a unique sigil.

An Example
In this set of examples we will show how Class::Accessor is automagically inferior to Moose at making accessors, because of Moose's ability to specify valid types.

Here we create a custom datatype, ie. NonMooseObject:

This is what you want your user to do:

This is what you don't want your user to do. In this example we show how easily a NonMooseObject can be abused. There is one important thing that is difficult to show in an example: the death might or might not occur on the call to. Hopefully, for the user and programmer, it dies on the call to new; but, let's assume you run for 42 days, and then something internally calls  on   when   does not contain a URI object. The result is then a bug that could be much harder to troubleshoot.

The pre-Moose days
We told ourselves this functionality, is more advanced and niche, isn't needed everywhere. To accomplish this functionally you much first decouple your module and. So not just is this solution ugly, but now you're back at having to write accessors. Baby Jesus cried around this point in time.

Invoking the Moose
Dredging up the past is boring and disturbing, so let's now look forward now, towards the light.

An Example
No more examples needed. You now either send in a  object to the constructor, or you die with an accompanying stack trace and Moose's default message telling you what you need to do.