Well it is time to make a choice! I started with three and took another good look at was available in the MooseX space on CPAN today and didn't see anything else that I think would do what I want. Though I was quite interested in Moose::Templated until I figured out it was a template system for rendering content utilizing roles rather that what I was looking for a template system to create roles and classes.
Anyway back to my choice.
At least it was easy to eliminate MooseX::ClassCompositor as it did not do what I wanted though I could see it use some-where else. To use it I would have to trash a good deal of code and have no 'Base' class just roles. Well AD&D is just a little too static for that but if I had a very large number of characters and classes like in the 5thEd. I might start out that way.
This is part 13 (and the final installment) of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at what comes next.
I suppose at the end of any long rumination on the past, it’s only natural to think about the future. I’ve tended to avoid pontificating on Perl’s prospects for a number of reasons, not the least of which is that I don’t have any special knowledge to share. I’m not an author of Perl books, a contributor to the Perl core, or even a particularly prolific creator or maintainer of CPAN modules.1 I don’t have any inside knowledge of Perl from hanging out with Larry, or the folks that run the Perl Foundation, or the current Pumpking (nor any past ones, for that matter). I’m just a regular Joe JAPH—admittedly one who has made his living off Perl for 17 years, well enough to support a nice house in southern California and a complement of five humans, three cats, one guinea pig, and a tank full of tropical fish, snails, and shrimp—but just a working schmoe nonetheless, whose opinion isn’t any better or smarter or wiser or more likely to be true than yours. So, you should definitely not listen to me.
Depending on the application, a person may have no name at all -- think about hospitals and automobile accidents, for example.
Thinking carefully about what name or names you need. Is this name for display to the user? Does it have to be used for email or postal mail? Should the name be sortable? There are lots of issues to consider.
For the less classically trained Occam's Razor or to dumb it down even more, the answer is staring you in the face, is the topic for tonight.
Well to make a short story long, I was happily programming along, in the zone if you will, when I was flustered by a small problem. How to tell if something is an object??
The problem occurred in a class pre-loader, it gladly recursively searches though a name-space and loads in classes for future use. There is some sanity checking such as making sure the file at least ends in '.pm' as don't want any silly subversion or '.pl' files loading do we?
Anyway at the tail end of the process we do something like this
If you need ordered key, value pairs, you can either use something like Tie::IxHash or a simple array of key, value pairs.
I found myself in the situation where I needed to extract just the keys from such an array.
There are a number of ways to do it, but which is the fastest? I tried a few pure Perl approaches, as well as List::Util::pairkeys (which as of this writing isn't yet in a stable release of Perl, assuming that List::Util remains in the core). The pure Perl approaches either use various means of flipping a binary toggle, or splice()ing through a sacrificial copy of the array.
The upcoming subroutine signatures in Perl aren't needed so that Perl can be "cool" (we're long past that). They're needed to make your code more correct.
I have a client that I sometimes write code for and they have the layers of their application nicely defined. Their front-end code makes AJAX calls back to an API written in Perl. That, in turn, calls their backend code, also written in Perl. Much of their API code resembles this:
Well my last post trying to work with MooseX::ClassCompositor was a bit of a bust as it is not what I needed. So onto the next one one my list 'MooseX::ShortCut::BuildInstance' so lets have a look and see what this one can do for me.
Well at first glance it seems a hybrid of the last two, it does follows the same basic pattern, give a base class add some roles and then get a instance. With this mod I don't have to build a factory class like I do for MoosX::Facotry but I can supply a base class which I could not do for MooseX::ClassCompositor so things look promising.
This one also has the best documentation but it still is very sparse but informative. The tests are a little more elaborate but still very basic and a funny thing he uses them in the synopsis in the POD haven't seen that often.
The smartmatch operator (~~) introduced in Perl 5.10 (and borrowed from Perl 6) has been the subject of much criticism. Its behaviour changes based on the types of its arguments (arrays vs hashes vs numbers vs strings vs ...). perlop lists over twenty different behaviours based on different combinations of arguments. Although the operator normally does what you want, what people would want from certain combinations (%hash ~~ @arr anybody?) is nor always clear.
(Aside: in Perl 6 which has a stronger type system, the behaviour of smartmatch is more predictable.)
For this reason, it has been proposed that the smartmatch operator be simplified, or perhaps even removed in a future version of Perl 5. To this end, Perl 5.18 has introduced some warnings about its experimental nature.
In my last post I had a look at how MooseX::Abstract::Factory worked and what it could do for me. Today I will continue down my little list and have a look at
'MooseX::ClassCompositor' and see if this one fits into what I am trying to do.
Well at first glance it seems this could really work for me. Start with an empty class and add in all the roles. So lets have a closer look. Like the last module the documentation is slim and the test suit contains little more than the synopsis so no pointers there.
Well this might be good for game time but I am not sure if it will work with my present class structure and trick. Seem I have to have everything a role. Well lets give it the old collage try
This is part 12 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at how to start putting it all together.
Last week I talked about the trade-offs of DWIM, and wondered if it might be time to try to make sense of all the various parts and perspectives. Thus, this is the end of the beginning.1 This is the convergence of all my reminiscences.
In my last post I identified three MooseX modules that might help me out and end the perhaps some tedious typing and bring a more structure design into my ADD game. The first of this is MooseX::Abstract::Factory.
Despite its name it does not actually create 'Abstract' classes in the sense of a class that cannot be instantiated like a 'Java Abstract Class'. I guess what they mean is a 'Factory that is Abstract' i.e. not tied to any one class or name-space.
OK, so that's maybe not 100% accurate, but we are looking for students who want to get paid to work with us. How can you get paid to work on MetaCPAN? There are currently two really great options: the Outreach Program for Women (OPfW) and the Google Summer of Code (GSoC).
What MetaCPAN needs from you is to help spread the word to interested students who may want to participate. Here's the pitch:
There are lots of things you can learn by working on the MetaCPAN stack. Our stack includes Catalyst, Plack, ElasticSearch, jQuery, Bootstrap and nginx. We also use Puppet for deployment and Vagrant + VirtualBox for development VMs. We have integration with Twitter, Github, PAUSE, Facebook and Google.
Chapter 1: Drone + Virus = Shock + Awe
Chapter 2: Using Drones to Hijack Government Policy
Chapter 3: Using Drones for Arson, Sabotage and Quarantine-busting
Chapter 4: A Child is Frightened of Drones
Chapter 5: The Drone Papers FAQ
-------
A note re Movable Type: Make sure you preview your articles 1 or 3 times. The 2nd time the display is blank, except for 2 buttons in the middle of the screen. Save and Re-edit entry.
