--- author: email: rafl@fsfe.org keyid: 742f2a428e635a5e name: Florian Ragwitz categories: - Perl date: 2009-08-19T08:27:25Z guid: a9b71ca9-4050-4322-9afe-2f5e2ee9a776 modified: 2009-08-19T08:27:25Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nYou've probably already heard of Sartak's awesome\nL.\n\nAs of version 0.25, MooseX::Declare provides some nice sugar for\nthat. This is what it looks like:\n\n lang:Perl\n use MooseX::Declare;\n\n role Counter (Str :$name) {\n has $name => (is => 'rw', isa => 'Int', default => 0);\n\n method \"increment_${name}\" {\n $self->$name( $self->$name + 1 );\n }\n\n method \"reset_${name}\" {\n $self->$name(0);\n }\n }\n\n class MyGame::Weapon {\n with Counter => { name => 'enchantment' };\n }\n\n class MyGame::Wand {\n with Counter => { name => 'zapped' };\n }\n\nJust thought I'd let you know, since i haven't gotten around to\nactually document this. In case you like it, have some spare\ntuits, and want to help out, the repository is\nL :-)\n\n=cut\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFKi7dGdC8qQo5jWl4RAkm2AJ9m1S3kzkHl1zgMQfh2bU9pqFLnVwCcCNpN\nEMIF5I5VMLWrpy/ESf3Bs14=\n=9SN1\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " You've probably already heard of Sartak's awesome MooseX::Role::Pa- rameterized. …" tags: - perl: 0 - moose: 0 - syntax: 0 text: " You've probably already heard of Sartak's awesome MooseX::Role::Pa-\n rameterized.\n\n As of version 0.25, MooseX::Declare provides some nice sugar for\n that. This is what it looks like:\n\n lang:Perl use MooseX::Declare;\n\n role Counter (Str :$name) { has $name => (is => 'rw', isa => 'In-\n t', default => 0);\n\n method \"increment_${name}\" { $self->$name( $self->$name + 1 ); }\n\n method \"reset_${name}\" { $self->$name(0); } }\n\n class MyGame::Weapon { with Counter => { name => 'enchant-\n ment' }; }\n\n class MyGame::Wand { with Counter => { name => 'zapped' }; }\n\n Just thought I'd let you know, since i haven't gotten around to ac-\n tually document this. In case you like it, have some spare tuits,\n and want to help out, the repository is right here :-)\n" title: Parameterized Roles with MooseX::Declare type: pod uri: http://perldition.org/articles/Parameterized%20Roles%20with%20MooseX%3A%3ADeclare.pod xhtml: "
\n

You've probably already heard of Sartak's awesome\nMooseX::Role::Parameterized.

\n

As of version 0.25, MooseX::Declare provides some nice sugar for\nthat. This is what it looks like:

\n
use MooseX::Declare;\n\nrole Counter (Str :$name) {\n  has $name => (is => 'rw', isa => 'Int', default => 0);\n\n  method "increment_${name}" {\n    $self->$name( $self->$name + 1 );\n  }\n\n  method "reset_${name}" {\n    $self->$name(0);\n  }\n}\n\nclass MyGame::Weapon {\n  with Counter => { name => 'enchantment' };\n}\n\nclass MyGame::Wand {\n  with Counter => { name => 'zapped' };\n}\n
\n

Just thought I'd let you know, since i haven't gotten around to\nactually document this. In case you like it, have some spare\ntuits, and want to help out, the repository is\nright here :-)

\n\n\n
" --- author: email: rafl@fsfe.org keyid: 742f2a428e635a5e name: Florian Ragwitz categories: - Perl date: 2009-05-08T22:51:11Z guid: 7f51c642-13c4-43aa-80c9-73663b73fe9c modified: 2009-05-08T22:53:28Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nI've been doing some contracting work for L<10gen|http://10gen.com>\nrecently. They have that rather cool open source document database\ncalled L and they wanted me to write a\nmodule to use that from Perl. I did that and the code is now available\non L and\nL.\n\nWriting that was fun, and I'm already looking forward to be able to\nuse MongoDB as a backend for\nL. I started writing\ncode for that and put it on\nL, but isn't\npassing all the tests just yet.\n\nIn related news, after finishing the MongoDB module, I'm available for\nother things again. So if you're looking for a\nL,\nL.\n\n=cut\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFKBLfodC8qQo5jWl4RAmVhAJ91KsH6+CX0i54MXm687lEjUs0rZwCeL4Nf\nwqzK9jT9aW7oWwnb6lKfbzQ=\n=dAd5\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " I've been doing some contracting work for 10gen recently. …" tags: - perl: 0 - kiokudb: 0 - mongodb: 0 text: " I've been doing some contracting work for 10gen recently. They have\n that rather cool open source document database called MongoDB and\n they wanted me to write a module to use that from Perl. I did that\n and the code is now available on CPAN and github.\n\n Writing that was fun, and I'm already looking forward to be able to\n use MongoDB as a backend for KiokuDB. I started writing code for\n that and put it on github, but isn't passing all the tests just yet.\n\n In related news, after finishing the MongoDB module, I'm available\n for other things again. So if you're looking for a Perl telecom-\n muter, let me know.\n" title: MongoDB on CPAN type: pod uri: http://perldition.org/articles/MongoDB%20on%20CPAN.pod xhtml: "
\n

I've been doing some contracting work for 10gen\nrecently. They have that rather cool open source document database\ncalled MongoDB and they wanted me to write a\nmodule to use that from Perl. I did that and the code is now available\non CPAN and\ngithub.

\n

Writing that was fun, and I'm already looking forward to be able to\nuse MongoDB as a backend for\nKiokuDB. I started writing\ncode for that and put it on\ngithub, but isn't\npassing all the tests just yet.

\n

In related news, after finishing the MongoDB module, I'm available for\nother things again. So if you're looking for a\nPerl telecommuter,\nlet me know.

\n\n\n
" --- author: email: rafl@fsfe.org keyid: 742f2a428e635a5e name: Florian Ragwitz categories: - Perl date: 2009-04-29T15:20:03Z guid: 13d6b55d-2935-43fe-a0fd-bfba692b06a0 modified: 2009-04-29T15:22:37Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nLots of CPAN distributions require some kind of graphical\nenvironment. Some of them even pop up windows, which not only very\nannoying, but also sometimes fails if you're using a tiled window\nmanager.\n\nTo test such distributions on a machine where no graphical environment\nis available or on your desktop while you're working and don't want to\nget annoyed to death you can use a fake X server, like Xvfb.\n\nThe easiest way to do that is to run\n\n lang:Bash\n $ xvfb-run -a make test\n\ninstead of a plain C. That'll automatically create a fake\nxserver, set up C and run C in that environment.\n\nThat works well for manually installing modules. When installing using\nC you can make things easier by writing a distropref.\n\nFirst, tell cpan where your distroprefs are. I use C<~/.cpan/prefs>:\n\n lang:Bash\n $ cpan\n cpan[1]> o conf init prefs_dir\n [...]\n \n Directory where to store default options/environment/dialogs for\n building modules that need some customization? [] /home/rafl/.cpan/prefs\n cpan[3]> o conf commit\n commit: wrote '/home/rafl/.cpan/CPAN/MyConfig.pm'\n\nNow write a distropref for the modules that need an X server and put\nit into your prefs dir as C\n\n ---\n match:\n distribution: |\n /(?x:Wx\n |Gtk2\n |Gnome2\n |... other modules requiring an X server\n )-\\d|\n test:\n commandline: \"xvfb-run -a make test\"\n\nNow the tests for Wx, Gtk2, Gnome2 and all other distributions you\nlist in that regex will be executed with a fake X server.\n\nI have yet to figure out how to write a distropref that just prepends\nto the test commandline instead of replacing it so I won't need to\nhave another pref for all modules using C.\n\n=cut\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFJ+HC9dC8qQo5jWl4RAl7JAJ4y9ubdkzkHw1fiH0gZYeKZG1Xm2wCfWY/P\nXj+fmSrSkoESejt0Cpykoms=\n=FtHr\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " Lots of CPAN distributions require some kind of graphical …" tags: - perl: 0 - cpan: 0 text: " Lots of CPAN distributions require some kind of graphical envi-\n ronment. Some of them even pop up windows, which not only very\n annoying, but also sometimes fails if you're using a tiled win-\n dow manager.\n\n To test such distributions on a machine where no graphical environ-\n ment is available or on your desktop while you're working and don't\n want to get annoyed to death you can use a fake X server, like Xvfb.\n\n The easiest way to do that is to run\n\n lang:Bash $ xvfb-run -a make test\n\n instead of a plain make test. That'll automatically create a fake\n xserver, set up DISPLAY and run make test in that environment.\n\n That works well for manually installing modules. When installing us-\n ing CPAN.pm you can make things easier by writing a distropref.\n\n First, tell cpan where your distroprefs are. I use ~/.cpan/prefs:\n\n lang:Bash $ cpan cpan[1]> o conf init prefs_dir [...] \n Directory where to store default options/environment/dialogs for\n building modules that need some customization? [] /home/rafl/.c-\n pan/prefs cpan[3]> o conf commit commit: wrote '/home/rafl/.c-\n pan/CPAN/MyConfig.pm'\n\n Now write a distropref for the modules that need an X server and put\n it into your prefs dir as X11.yml\n\n ---\n match: distribution: | /(?x:Wx |Gtk2 |Gnome2\n |... other modules requiring an X server\n )-\\d| test: commandline: \"xvfb-run -a make test\"\n\n Now the tests for Wx, Gtk2, Gnome2 and all other distributions you\n list in that regex will be executed with a fake X server.\n\n I have yet to figure out how to write a distropref that just\n prepends to the test commandline instead of replacing it so I won't\n need to have another pref for all modules using Module::Build.\n" title: Running tests that require an X server type: pod uri: http://perldition.org/articles/Running%20tests%20that%20require%20an%20X%20server.pod xhtml: "
\n

Lots of CPAN distributions require some kind of graphical\nenvironment. Some of them even pop up windows, which not only very\nannoying, but also sometimes fails if you're using a tiled window\nmanager.

\n

To test such distributions on a machine where no graphical environment\nis available or on your desktop while you're working and don't want to\nget annoyed to death you can use a fake X server, like Xvfb.

\n

The easiest way to do that is to run

\n
$ xvfb-run -a make test\n
\n

instead of a plain make test. That'll automatically create a fake\nxserver, set up DISPLAY and run make test in that environment.

\n

That works well for manually installing modules. When installing using\nCPAN.pm you can make things easier by writing a distropref.

\n

First, tell cpan where your distroprefs are. I use ~/.cpan/prefs:

\n
$ cpan\ncpan[1]> o conf init prefs_dir\n[...]\n<prefs_dir>\nDirectory where to store default options/environment/dialogs for\nbuilding modules that need some customization? [] /home/rafl/.cpan/prefs\ncpan[3]> o conf commit\ncommit: wrote '/home/rafl/.cpan/CPAN/MyConfig.pm'\n
\n

Now write a distropref for the modules that need an X server and put\nit into your prefs dir as X11.yml

\n
---\nmatch:\n  distribution: |\n    /(?x:Wx\n      |Gtk2\n      |Gnome2\n      |... other modules requiring an X server\n    )-\\d|\ntest:\n  commandline: "xvfb-run -a make test"\n
\n

Now the tests for Wx, Gtk2, Gnome2 and all other distributions you\nlist in that regex will be executed with a fake X server.

\n

I have yet to figure out how to write a distropref that just prepends\nto the test commandline instead of replacing it so I won't need to\nhave another pref for all modules using Module::Build.

\n\n\n
" --- author: email: rafl@fsfe.org keyid: 742f2a428e635a5e name: Florian Ragwitz categories: - Perl date: 2009-04-28T06:09:31Z guid: 97a76a6d-4019-4554-9993-2de23bde7e39 modified: 2009-04-28T06:20:16Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nFor quite some time perl provided a form of C declarations that\nincludes a type name, like this:\n\n lang:Perl\n my Str $x = 'foo';\n\nHowever, that didn't do anything useful, until Vincent Pit came along\nand wrote the excellent\nL\nmodule, which allows you to extend the semantics of typed lexicals and\nactually make them do something useful. For that, it simply invokes a\ncallback for every C declaration with a type in the scopes it is\nloaded. Within that callback you get the variable that is being\ndeclared as well as the name of the type used in the declaration.\n\nWe also have Moose type constraints and the great\nL module,\nthat allows us to define our own type libraries and import the type\nconstraints into other modules.\n\nLet's glue those modules together. Consider this code:\n\n lang:Perl\n use MooseX::Types::Moose qw/Int/;\n use Lexical::Types;\n my Int $x = 42;\n\nThe first problem is that the perl compiler expects a package with the\nname of the type used in C to exist. If there's no such package\ncompilation will fail.\n\nCreating top-level namespaces for all the types we want to use would\nobviously suck. Luckily the compiler will also try to look for a\nfunction with the name of the type in the current scope. If that\nexists and is inlineable, it will call that function and use the\nreturn value as a package name.\n\nIn the above code snippet an C function already exists. We\nimported that from C. Unfortunately it isn't\ninlineable. Even if it were, compilation would still fail, because it\nwould return a C instead of a valid\npackage name.\n\nTo fix that, let's rewrite the code to this:\n\n lang:Perl\n use MooseX::Types::Moose qw/Int/;\n use MooseX::Lexical::Types qw/Int/;\n my Int $x = 42;\n\nLet's also write a MooseX::Lexical::Types module that replaces\nexisting imported type exports with something that can be inlined and\nreturns an existing package name based on the type constraint's name.\n\n lang:Perl\n package MooseX::Lexical::Types;\n\n use Class::MOP;\n use MooseX::Types::Util qw/has_available_type_export/;\n use namespace::autoclean;\n\n sub import {\n my ($class, @args) = @_;\n my $caller = caller();\n\n my $meta = Class::MOP::class_of($caller) || Class::MOP::Class->initialize($caller);\n\n for my $type_name (@args) {\n # get the type constraint by introspecting the caller\n my $type_constraint = has_available_type_export($caller, $type_name);\n\n my $package = 'MooseX::Lexical::Types::TYPE::' . $type_constraint->name;\n Class::MOP::Class->create($package);\n $meta->add_package_symbol('&'.$type_name => sub () { $package });\n }\n\n Lexical::Types->import; # enable Lexical::Types for the caller\n }\n\n 1;\n\nWith that the example code now compiles. Unfortunately it breaks every\nother usecase of MooseX::Types. The export will still need to return a\nC at run time so this will continue to\nwork:\n\n lang:Perl\n has some_attribute => (is => 'ro', isa => Int);\n\nSo instead of returning a plain package name from our exported\nfunction we will return an object that delegates all method calls to\nthe actual type constraint, but evaluates to our special package name\nwhen used as a string:\n\n lang:Perl\n my $decorator = MooseX::Lexical::Types::TypeDecorator->new($type_constraint);\n $meta->add_package_symbol('&'.$type_name => sub () { $decorator });\n\nand:\n\n lang:Perl\n package MooseX::Lexical::Types::TypeDecorator;\n use Moose;\n use namespace::autoclean;\n\n # MooseX::Types happens to already have a class that doesn't do much\n # more than delegating to a real type constraint!\n extends 'MooseX::Types::TypeDecorator';\n\n use overload '\"\"' => sub {\n 'MooseX::Lexical::Types::TYPE::' . $_[0]->__type_constraint->name\n };\n\n 1;\n\nNow we're able to use C as usual and have Lexical::Types invoke\nits callback on C. Within that\ncallback we will need the real type constraint again, but as it is\ninvoked as a class method with no good way to pass in additional\narguments, we will need to store the type constraint somewhere. I\nchoose to simply add a method to the type class we create when\nconstructing our export. After that, all we need is to implement our\nLexical::Types callback. We will put that in a class all our type\nclasses will inherit from:\n\n lang:Perl\n Class::MOP::Class->create(\n $package => (\n superclasses => ['MooseX::Lexical::Types::TypedScalar'],\n methods => {\n get_type_constraint => sub { $type_constraint },\n },\n ),\n );\n\nThe Lexical::Types callback will now need to tie things together by\nmodifying the declared variable so it will automatically validate\nvalues against the type constraint when being assigned to. There are\nseveral ways of doing this. Using C on the declared variable\nwould probable be the easiest thing to do. However, I decided to use\nL\n(also written by Vincent Pit - did I mention he's awesome?), because\nit's mostly invisible at the perl level and also performs rather well\n(not that it'd matter, given that validation itself is relatively\nslow):\n\n lang:Perl\n package MooseX::Lexical::Types::TypedScalar;\n\n use Carp qw/confess/;\n use Variable::Magic qw/wizard cast/;\n use namespace::autoclean;\n\n my $wiz = wizard\n # store the type constraint in the data attached to the magic\n data => sub { $_[1]->get_type_constraint },\n # when assigning to the variable, fail if we can't validate the\n # new value ($_[0]) against the type constraint ($_[1])\n set => sub {\n if (defined (my $msg = $_[1]->validate(${ $_[0] }))) {\n confess $msg;\n }\n ();\n };\n\n sub TYPEDSCALAR {\n # cast $wiz on the variable in $_[1]. pass the type package name\n # in $_[0] to the wizard's data construction callback.\n cast $_[1], $wiz, $_[0];\n ();\n }\n\n 1;\n\nWith this, our example code now works. If someone wants to assign,\nsay, C<'foo'> to the variable declared as C our magic\ncallback will be invoked, try to validate the value against the type\nconstraint and fail loudly. B\n\nThe code for all this is available\nL and should also\nbe on CPAN shortly.\n\nYou might notice warnings about mismatching prototypes. Those are\ncaused by Class::MOP and fixed in the git version of it, so they'll go\naway with the next release.\n\nThere's still a couple of caveats, but please see L\nfor that.\n\n=cut\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFJ9qAgdC8qQo5jWl4RAni9AJoDwsG/8iNd2MlXvBLG6+1IOXCCnwCfZnys\nuUwBX0DArfYxN0EJf48Op2w=\n=xSW5\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " For quite some time perl provided a form of …" tags: - perl: 0 - types: 0 - moose: 0 - syntax: 0 text: " For quite some time perl provided a form of my declarations that in-\n cludes a type name, like this:\n\n lang:Perl my Str $x = 'foo';\n\n However, that didn't do anything useful, until Vincent Pit came a-\n long and wrote the excellent Lexical::Types module, which allows you\n to extend the semantics of typed lexicals and actually make them do\n something useful. For that, it simply invokes a callback for every\n my declaration with a type in the scopes it is loaded. Within that\n callback you get the variable that is being declared as well as the\n name of the type used in the declaration.\n\n We also have Moose type constraints and the great MooseX::Types mod-\n ule, that allows us to define our own type libraries and import the\n type constraints into other modules.\n\n Let's glue those modules together. Consider this code:\n\n lang:Perl use MooseX::Types::Moose qw/Int/; use Lexical::Types; my\n Int $x = 42;\n\n The first problem is that the perl compiler expects a package with\n the name of the type used in my to exist. If there's no such package\n compilation will fail.\n\n Creating top-level namespaces for all the types we want to use would\n obviously suck. Luckily the compiler will also try to look for a\n function with the name of the type in the current scope. If that ex-\n ists and is inlineable, it will call that function and use the re-\n turn value as a package name.\n\n In the above code snippet an Int function already exists. We im-\n ported that from MooseX::Types::Moose. Unfortunately it isn't in-\n lineable. Even if it were, compilation would still fail, because\n it would return a Moose::Meta::TypeConstraint instead of a valid\n package name.\n\n To fix that, let's rewrite the code to this:\n\n lang:Perl use MooseX::Types::Moose qw/Int/; use MooseX::Lexi-\n cal::Types qw/Int/; my Int $x = 42;\n\n Let's also write a MooseX::Lexical::Types module that replaces\n existing imported type exports with something that can be in-\n lined and returns an existing package name based on the type\n constraint's name.\n\n lang:Perl package MooseX::Lexical::Types;\n\n use Class::MOP; use MooseX::Types::Util qw/has_available_type_ex-\n port/; use namespace::autoclean;\n\n sub import { my ($class, @args) = @_; my $caller = caller();\n\n my $meta = Class::MOP::class_of($caller) ||\n Class::MOP::Class->initialize($caller);\n\n for my $type_name (@args) {\n # get the type constraint by introspecting the caller\n my $type_constraint = has_available_type_export($caller,\n $type_name);\n\n my $package = 'MooseX::Lexical::Types::TYPE::' . $type_-\n constraint->name; Class::MOP::Class->create($package);\n $meta->add_package_symbol('&'.$type_name => sub () { $-\n package }); }\n\n Lexical::Types->import; # enable Lexical::Types for the caller\n }\n\n 1;\n\n With that the example code now compiles. Unfortunately it breaks ev-\n ery other usecase of MooseX::Types. The export will still need to\n return a Moose::Meta::TypeConstraint at run time so this will con-\n tinue to work:\n\n lang:Perl has some_attribute => (is => 'ro', isa => Int);\n\n So instead of returning a plain package name from our exported func-\n tion we will return an object that delegates all method calls to the\n actual type constraint, but evaluates to our special package name\n when used as a string:\n\n lang:Perl my $decorator = MooseX::Lexical::Types::TypeDecora-\n tor->new($type_constraint); $meta->add_package_symbol('&'.$type_-\n name => sub () { $decorator });\n\n and:\n\n lang:Perl package MooseX::Lexical::Types::TypeDecorator; use\n Moose; use namespace::autoclean;\n\n # MooseX::Types happens to already have a class that doesn't do\n # much more than delegating to a real type constraint!\n extends 'MooseX::Types::TypeDecorator';\n\n use overload '\"\"' => sub { 'MooseX::Lexical::Types::TYPE::' .\n $_[0]->__type_constraint->name };\n\n 1;\n\n Now we're able to use Int as usual and have Lexical::Types invoke\n its callback on MooseX::Lexical::Types::TYPE::Int. Within that call-\n back we will need the real type constraint again, but as it is in-\n voked as a class method with no good way to pass in additional argu-\n ments, we will need to store the type constraint somewhere. I choose\n to simply add a method to the type class we create when constructing\n our export. After that, all we need is to implement our Lexi-\n cal::Types callback. We will put that in a class all our type class-\n es will inherit from:\n\n lang:Perl Class::MOP::Class->create( $package => ( superclasses =>\n ['MooseX::Lexical::Types::TypedScalar'], methods => { get_type_-\n constraint => sub { $type_constraint }, }, ), );\n\n The Lexical::Types callback will now need to tie things together by\n modifying the declared variable so it will automatically validate\n values against the type constraint when being assigned to. There are\n several ways of doing this. Using tie on the declared variable would\n probable be the easiest thing to do. However, I decided to use Vari-\n able::Magic (also written by Vincent Pit - did I mention he's awe-\n some?), because it's mostly invisible at the perl level and also\n performs rather well (not that it'd matter, given that validation\n itself is relatively slow):\n\n lang:Perl package MooseX::Lexical::Types::TypedScalar;\n\n use Carp qw/confess/; use Variable::Magic qw/wizard cast/; use\n namespace::autoclean;\n\n my $wiz = wizard\n # store the type constraint in the data attached to the magic\n data => sub { $_[1]->get_type_constraint },\n # when assigning to the variable, fail if we can't validate\n # the new value ($_[0]) against the type constraint ($_[1])\n set => sub { if (defined (my $msg = $_[1]->validate(${ $_[0]\n }))) { confess $msg; } (); };\n\n sub TYPEDSCALAR {\n # cast $wiz on the variable in $_[1]. pass the type package\n # name in $_[0] to the wizard's data construction callback.\n cast $_[1], $wiz, $_[0]; (); }\n\n 1;\n\n With this, our example code now works. If someone wants to assign,\n say, 'foo' to the variable declared as my Int $x our magic callback\n will be invoked, try to validate the value against the type con-\n straint and fail loudly. WIN!\n\n The code for all this is available github and should also be on\n CPAN shortly.\n\n You might notice warnings about mismatching prototypes. Those are\n caused by Class::MOP and fixed in the git version of it, so they'll\n go away with the next release.\n\n There's still a couple of caveats, but please see the documenta-\n tion for that.\n" title: Implementing Typed Lexical Variables type: pod uri: http://perldition.org/articles/Implementing%20Typed%20Lexical%20Variables.pod xhtml: "
\n

For quite some time perl provided a form of my declarations that\nincludes a type name, like this:

\n
my Str $x = 'foo';\n
\n

However, that didn't do anything useful, until Vincent Pit came along\nand wrote the excellent\nLexical::Types\nmodule, which allows you to extend the semantics of typed lexicals and\nactually make them do something useful. For that, it simply invokes a\ncallback for every my declaration with a type in the scopes it is\nloaded. Within that callback you get the variable that is being\ndeclared as well as the name of the type used in the declaration.

\n

We also have Moose type constraints and the great\nMooseX::Types module,\nthat allows us to define our own type libraries and import the type\nconstraints into other modules.

\n

Let's glue those modules together. Consider this code:

\n
use MooseX::Types::Moose qw/Int/;\nuse Lexical::Types;\nmy Int $x = 42;\n
\n

The first problem is that the perl compiler expects a package with the\nname of the type used in my to exist. If there's no such package\ncompilation will fail.

\n

Creating top-level namespaces for all the types we want to use would\nobviously suck. Luckily the compiler will also try to look for a\nfunction with the name of the type in the current scope. If that\nexists and is inlineable, it will call that function and use the\nreturn value as a package name.

\n

In the above code snippet an Int function already exists. We\nimported that from MooseX::Types::Moose. Unfortunately it isn't\ninlineable. Even if it were, compilation would still fail, because it\nwould return a Moose::Meta::TypeConstraint instead of a valid\npackage name.

\n

To fix that, let's rewrite the code to this:

\n
use MooseX::Types::Moose qw/Int/;\nuse MooseX::Lexical::Types qw/Int/;\nmy Int $x = 42;\n
\n

Let's also write a MooseX::Lexical::Types module that replaces\nexisting imported type exports with something that can be inlined and\nreturns an existing package name based on the type constraint's name.

\n
package MooseX::Lexical::Types;\n\nuse Class::MOP;\nuse MooseX::Types::Util qw/has_available_type_export/;\nuse namespace::autoclean;\n\nsub import {\n    my ($class, @args) = @_;\n    my $caller = caller();\n\n    my $meta = Class::MOP::class_of($caller) || Class::MOP::Class->initialize($caller);\n\n    for my $type_name (@args) {\n        # get the type constraint by introspecting the caller\n        my $type_constraint = has_available_type_export($caller, $type_name);\n\n        my $package = 'MooseX::Lexical::Types::TYPE::' . $type_constraint->name;\n        Class::MOP::Class->create($package);\n        $meta->add_package_symbol('&'.$type_name => sub () { $package });\n    }\n\n    Lexical::Types->import; # enable Lexical::Types for the caller\n}\n\n1;\n
\n

With that the example code now compiles. Unfortunately it breaks every\nother usecase of MooseX::Types. The export will still need to return a\nMoose::Meta::TypeConstraint at run time so this will continue to\nwork:

\n
has some_attribute => (is => 'ro', isa => Int);\n
\n

So instead of returning a plain package name from our exported\nfunction we will return an object that delegates all method calls to\nthe actual type constraint, but evaluates to our special package name\nwhen used as a string:

\n
my $decorator = MooseX::Lexical::Types::TypeDecorator->new($type_constraint);\n$meta->add_package_symbol('&'.$type_name => sub () { $decorator });\n
\n

and:

\n
package MooseX::Lexical::Types::TypeDecorator;\nuse Moose;\nuse namespace::autoclean;\n\n# MooseX::Types happens to already have a class that doesn't do much\n# more than delegating to a real type constraint!\nextends 'MooseX::Types::TypeDecorator';\n\nuse overload '""' => sub {\n    'MooseX::Lexical::Types::TYPE::' . $_[0]->__type_constraint->name\n};\n\n1;\n
\n

Now we're able to use Int as usual and have Lexical::Types invoke\nits callback on MooseX::Lexical::Types::TYPE::Int. Within that\ncallback we will need the real type constraint again, but as it is\ninvoked as a class method with no good way to pass in additional\narguments, we will need to store the type constraint somewhere. I\nchoose to simply add a method to the type class we create when\nconstructing our export. After that, all we need is to implement our\nLexical::Types callback. We will put that in a class all our type\nclasses will inherit from:

\n
Class::MOP::Class->create(\n    $package => (\n        superclasses => ['MooseX::Lexical::Types::TypedScalar'],\n        methods      => {\n            get_type_constraint => sub { $type_constraint },\n        },\n    ),\n);\n
\n

The Lexical::Types callback will now need to tie things together by\nmodifying the declared variable so it will automatically validate\nvalues against the type constraint when being assigned to. There are\nseveral ways of doing this. Using tie on the declared variable\nwould probable be the easiest thing to do. However, I decided to use\nVariable::Magic\n(also written by Vincent Pit - did I mention he's awesome?), because\nit's mostly invisible at the perl level and also performs rather well\n(not that it'd matter, given that validation itself is relatively\nslow):

\n
package MooseX::Lexical::Types::TypedScalar;\n\nuse Carp qw/confess/;\nuse Variable::Magic qw/wizard cast/;\nuse namespace::autoclean;\n\nmy $wiz = wizard\n    # store the type constraint in the data attached to the magic\n    data => sub { $_[1]->get_type_constraint },\n    # when assigning to the variable, fail if we can't validate the\n    # new value ($_[0]) against the type constraint ($_[1])\n    set  => sub {\n        if (defined (my $msg = $_[1]->validate(${ $_[0] }))) {\n            confess $msg;\n        }\n        ();\n    };\n\nsub TYPEDSCALAR {\n    # cast $wiz on the variable in $_[1]. pass the type package name\n    # in $_[0] to the wizard's data construction callback.\n    cast $_[1], $wiz, $_[0];\n    ();\n}\n\n1;\n
\n

With this, our example code now works. If someone wants to assign,\nsay, 'foo' to the variable declared as my Int $x our magic\ncallback will be invoked, try to validate the value against the type\nconstraint and fail loudly. WIN!

\n

The code for all this is available\ngithub and should also\nbe on CPAN shortly.

\n

You might notice warnings about mismatching prototypes. Those are\ncaused by Class::MOP and fixed in the git version of it, so they'll go\naway with the next release.

\n

There's still a couple of caveats, but please see the documentation\nfor that.

\n\n\n
" --- author: email: rafl@fsfe.org keyid: 742f2a428e635a5e name: Florian Ragwitz categories: - Perl date: 2009-04-26T08:13:18Z guid: c42e982b-d436-4680-b794-973c516befec modified: 2009-04-26T09:14:50Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nFor a long time the L has been using code attributes\nto allow users to declare actions that certain URLs get dispatched to.\nThat looks something like this:\n\n lang:Perl\n sub base : Chained('/') PathPart('') CaptureArgs(0) { ... }\n sub index : Chained('base') PathPart('') Args(0) { ... }\n sub default : Chained('base') PathPart('') Args { ... }\n\nIt's a nice and clean syntax that keeps all important information\nright next to the method it belongs to.\n\nHowever, attributes in perl have a couple of limitations. For one, the\ninterface the perl core provides to use them is horrible and doesn't\nprovide nearly enough information to do a lot of things, but most\nimportantly attributes are just plain strings. That means you will\nneed to parse something like C<\"Chained('base')\"> into\nC<< (Chained => 'base') >> yourself to make proper use of them.\n\nWhile that's easy for the above example, it can be very hard in the\ngeneral case because only perl can parse Perl. It's one of the reasons\nyou can't use L to apply\nparameterized roles to your action instances, because parsing\nparameters out of things like\nC<< Does(SomeRole => { names => [qw/affe tiger/], answer_re => qr/42/ }) >>\nwould be awful and wrong.\n\nWith Catalyst 5.8 most of the attribute related code has been removed\nfrom the internals. It's now using L to do\nall the heavy lifting. Also the internals of how actions are\nregistered have been refactored to make it easier to implement\nalternate ways without changing the Catalyst core.\n\nAs a proof of concept for this I implemented a new way of declaring\nactions that's very similar to how L provides it's sugar\nfunctions. You can get it from\nL.\n\nWith that, the above example looks like this:\n\n lang:Perl\n action base => (Chained => '/', PathPart => '', CaptureArgs => 0) => sub { ... };\n action index => (Chained => 'base', PathPart => '', Args => 0 ) => sub { ... };\n action default => (Chained => 'base', PathPart => '', Args => undef) => sub { ... };\n\n\nIt also moves method declaration from compiletime to runtime, making\nthis possible:\n\n lang:Perl\n for my $action (qw/foo bar baz/) {\n action $action => (Chained => 'somewhere', Args => 0) => sub {\n my ($self, $ctx) = @_;\n $ctx->stash->{ $action } = $ctx->model('Foo')->get_stuff($action);\n };\n }\n\nAdmittedly, that's all very ugly, but illustrates well what kind of\nthings we're able to do now. But it doesn't need to be ugly. With\nL we have a great tool to add our own awesome syntax\nto perl, similar to how things like L,\nL and L do.\n\nSo how would a declarative syntax for Catalyst controllers look like?\nI don't know. Ideas include something like this:\n\n under /some/where, action foo ('foo', $id) { ... }\n\nto mean:\n\n sub foo : Chained('/some/where') PathPart('foo') CaptureArgs(1) { ... }\n\nAdding Moose type constraints to this would be interesting, too, and\nmake validation of captures and arguments a lot easier. Multi dispatch\nsimilar to MooseX::MultiMethods could be handy as well:\n\n under /some/where {\n action ('foo', Int $id) {\n # find and stash an item by id\n }\n action ('foo', Str $name) {\n # search items using $name\n }\n action ('foo', Any $thing) {\n # display error page\n }\n }\n\nSo you see there are a lot of possibilities that should be\nexplored. Unfortunately I have no idea what kind of syntax and\nfeatures people would like to have, so your feedback on this would be\nmuch appreciated. :-)\n\n=cut\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFJ9CYKdC8qQo5jWl4RAsRKAJ9Yad61aq7PRrSOiSV4+uFOWQuLRQCeKtwG\n0UpKH9fhZnP//tWX66Ispf0=\n=Lray\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " For a long time the Catalyst Framework has been …" tags: - perl: 0 - syntax: 0 - catalyst: 0 text: " For a long time the Catalyst Framework has been using code at-\n tributes to allow users to declare actions that certain URLs get\n dispatched to. That looks something like this:\n\n lang:Perl sub base : Chained('/') PathPart('') CaptureArgs(0) {\n ... } sub index : Chained('base') PathPart('') Args(0) { ... } sub\n default : Chained('base') PathPart('') Args { ... }\n\n It's a nice and clean syntax that keeps all important information\n right next to the method it belongs to.\n\n However, attributes in perl have a couple of limitations. For one,\n the interface the perl core provides to use them is horrible and\n doesn't provide nearly enough information to do a lot of things, but\n most importantly attributes are just plain strings. That means you\n will need to parse something like \"Chained('base')\" into (Chained =>\n 'base') yourself to make proper use of them.\n\n While that's easy for the above example, it can be very hard in the\n general case because only perl can parse Perl. It's one of the rea-\n sons you can't use Catalyst::Controller::ActionRole to apply parame-\n terized roles to your action instances, because parsing parameters\n out of things like Does(SomeRole => { names => [qw/affe tiger/], an-\n swer_re => qr/42/ }) would be awful and wrong.\n\n With Catalyst 5.8 most of the attribute related code has been re-\n moved from the internals. It's now using MooseX::MethodAttributes to\n do all the heavy lifting. Also the internals of how actions are reg-\n istered have been refactored to make it easier to implement alter-\n nate ways without changing the Catalyst core.\n\n As a proof of concept for this I implemented a new way of declaring\n actions that's very similar to how Moose provides it's sugar func-\n tions. You can get it from github.\n\n With that, the above example looks like this:\n\n lang:Perl action base => (Chained => '/', PathPart => '', Cap-\n tureArgs => 0) => sub { ... }; action index => (Chained => 'base',\n PathPart => '', Args => 0 ) => sub { ... }; action default =>\n (Chained => 'base', PathPart => '', Args => undef) => sub { ... };\n\n It also moves method declaration from compiletime to runtime, making\n this possible:\n\n lang:Perl for my $action (qw/foo bar baz/) { action $action =>\n (Chained => 'somewhere', Args => 0) => sub { my ($self, $ctx) =\n @_; $ctx->stash->{ $action } = $ctx->model('Foo')->get_stuff($ac-\n tion); }; }\n\n Admittedly, that's all very ugly, but illustrates well what kind of\n things we're able to do now. But it doesn't need to be ugly. With\n Devel::Declare we have a great tool to add our own awesome syntax to\n perl, similar to how things like MooseX::Method::Signatures,\n MooseX::MultiMethods and MooseX::Declare do.\n\n So how would a declarative syntax for Catalyst controllers look\n like? I don't know. Ideas include something like this:\n\n under /some/where, action foo ('foo', $id) { ... }\n\n to mean:\n\n sub foo : Chained('/some/where') PathPart('foo') Cap-\n tureArgs(1) { ... }\n\n Adding Moose type constraints to this would be interesting, too, and\n make validation of captures and arguments a lot easier. Multi dis-\n patch similar to MooseX::MultiMethods could be handy as well:\n\n under /some/where { action ('foo', Int $id) {\n # find and stash an item by id\n } action ('foo', Str $name) {\n # search items using $name\n } action ('foo', Any $thing) {\n # display error page\n } }\n\n So you see there are a lot of possibilities that should be ex-\n plored. Unfortunately I have no idea what kind of syntax and fea-\n tures people would like to have, so your feedback on this would be\n much appreciated.\n :-)\n" title: Declaring Catalyst Actions type: pod uri: http://perldition.org/articles/Declaring%20Catalyst%20Actions.pod xhtml: "
\n

For a long time the Catalyst Framework has been using code attributes\nto allow users to declare actions that certain URLs get dispatched to.\nThat looks something like this:

\n
sub base    : Chained('/')    PathPart('') CaptureArgs(0) { ... }\nsub index   : Chained('base') PathPart('') Args(0)        { ... }\nsub default : Chained('base') PathPart('') Args           { ... }\n
\n

It's a nice and clean syntax that keeps all important information\nright next to the method it belongs to.

\n

However, attributes in perl have a couple of limitations. For one, the\ninterface the perl core provides to use them is horrible and doesn't\nprovide nearly enough information to do a lot of things, but most\nimportantly attributes are just plain strings. That means you will\nneed to parse something like "Chained('base')" into\n(Chained => 'base') yourself to make proper use of them.

\n

While that's easy for the above example, it can be very hard in the\ngeneral case because only perl can parse Perl. It's one of the reasons\nyou can't use Catalyst::Controller::ActionRole to apply\nparameterized roles to your action instances, because parsing\nparameters out of things like\nDoes(SomeRole => { names => [qw/affe tiger/], answer_re => qr/42/ })\nwould be awful and wrong.

\n

With Catalyst 5.8 most of the attribute related code has been removed\nfrom the internals. It's now using MooseX::MethodAttributes to do\nall the heavy lifting. Also the internals of how actions are\nregistered have been refactored to make it easier to implement\nalternate ways without changing the Catalyst core.

\n

As a proof of concept for this I implemented a new way of declaring\nactions that's very similar to how Moose provides it's sugar\nfunctions. You can get it from\ngithub.

\n

With that, the above example looks like this:

\n
action base    => (Chained => '/',    PathPart => '', CaptureArgs => 0) => sub { ... };\naction index   => (Chained => 'base', PathPart => '', Args    => 0    ) => sub { ... };\naction default => (Chained => 'base', PathPart => '', Args    => undef) => sub { ... };\n\n\n
\n

It also moves method declaration from compiletime to runtime, making\nthis possible:

\n
for my $action (qw/foo bar baz/) {\n    action $action => (Chained => 'somewhere', Args => 0) => sub {\n        my ($self, $ctx) = @_;\n        $ctx->stash->{ $action } = $ctx->model('Foo')->get_stuff($action);\n    };\n}\n
\n

Admittedly, that's all very ugly, but illustrates well what kind of\nthings we're able to do now. But it doesn't need to be ugly. With\nDevel::Declare we have a great tool to add our own awesome syntax\nto perl, similar to how things like MooseX::Method::Signatures,\nMooseX::MultiMethods and MooseX::Declare do.

\n

So how would a declarative syntax for Catalyst controllers look like?\nI don't know. Ideas include something like this:

\n
under /some/where, action foo ('foo', $id) { ... }\n
\n

to mean:

\n
sub foo : Chained('/some/where') PathPart('foo') CaptureArgs(1) { ... }\n
\n

Adding Moose type constraints to this would be interesting, too, and\nmake validation of captures and arguments a lot easier. Multi dispatch\nsimilar to MooseX::MultiMethods could be handy as well:

\n
under /some/where {\n    action ('foo', Int $id) {\n        # find and stash an item by id\n    }\n    action ('foo', Str $name) {\n        # search items using $name\n    }\n    action ('foo', Any $thing) {\n        # display error page\n    }\n}\n
\n

So you see there are a lot of possibilities that should be\nexplored. Unfortunately I have no idea what kind of syntax and\nfeatures people would like to have, so your feedback on this would be\nmuch appreciated. :-)

\n\n\n
"