Often we hear people talk about making your programming more "data-driven". When you can convert procedural code to a data structure (generally with a small procedural driver), instead of replicating procedural code, you just add another entry to your data structure. This is great with dispatch tables, repetitive chunks of code and state machines. However, there is a hidden benefit of it which will not only make you a better programmer, but it will make later maintenance programmers fail to notice a common flaw that your code lacks. They'll curse you if you have the flaw, but if you don't have it, they'll find that data-driven sections of your code are so easy to work with that they won't even think about it.
May round schedule will be similar to the March round, with several changes as below.
- Longer period to solicit community feedback
- Longer voting period
- Shorter CFP period
In the long run, CFP period should be shortened further as every round will look the same and preparation can be done beforehand. Or even easier, we may always keep the CFP open and evaluate the applications every two months.
Here is the May schedule:
- May 1: CFP opens
- May 10: CFP closes
- May 11: Solicit public feedback
- May 22: Voting
- May 31: Announcement of the results
CFP will be posted at news.perlfoundation.org.
The following data is from a 64bit perl-5.19.10 (i.e. 32 bit jenkins - corrected from 64 bit siphash - which randomly shuffles the 2 first entries of collisions), running the core test suite with -DH.
number of hash keys:
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.
So lets give it a try
So what’s new?
- Follow the meta-2 phase-requirements naming.
- The ablity to recast phase-requirements.
Plus theres more
- App::Midgen v0.30 which was a refactor to support Perl 5.8.x
A Couple of other blogs that now make sense to share with you
- midgen 0.28 plus
- Flowchart showing logic for RuntimeRecommends
- An enhancement to output infile to include Installed files
- mro - MRO::Compat catch
- issue #6.
- The Catch
for the rest of the blog go here
Any comments leave them here.
The following is posted on behalf of Roman Filippov and Al Newkirk, kindly share your thoughts on the mentioned points.
I would like to propose the following items for discussion, in no particular order. This is just a brain dump of the ideas I have been thinking for a while now.
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
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.