A Date with CPAN, Part 6: Time Won't Give Me Time

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]


Last time I added Time::ParseDate support to our date class, which made it fairly usable, if still incomplete.  This time I decided to concentrate on getting a first cut at our datetime class.

In many ways, the datetime class is simpler than the date class, because it doesn’t need to do anything fancy like truncate to midnight or try to ignore times and timezones when parsing.  Of course, datetimes do have to consider timezones, but I decided to defer that thorny issue until next time.

The problem with Exporters (Meet Importer)

The problem with Exporters

With Exporter, and most exporter tools we have failed to separate concerns. Exporting fundamentally involves 2 parties: exporter and importer. Historically however we have only ever concerned ourselves with the exporter. The "standard" way of dealing with this in perl has been to have a module that provides exports use it's import() method to inject symbols into the importer's namespace.

What if we did this with other similar concepts? What if instead of:

use base 'foo';

we had:

package My::Base;

# Gives us an import() method that sets @{caller::ISA} = __PACKAGE__
use base;

...

package My::Subclass;
use Base::Class; #Automatically sets @ISA

Most of you are probably cringing right now. I know in the past I have actually used this pattern and gotten slapped on the wrist for it (rightly so). But this is essentially what we are doing with our current exporters.

Pure-Perl XML

In the past I sometimes used XML::Tiny and I found it perfect for the job. Agreed, I had to struggle only with very little and under-control XML, so I knew I could do without a full-fledged XML Parser.

A pretty stupid idea...

If you're a Perl developer in the UK, I will literally send you free money by email: http://eepurl.com/bNSF9P

A Naïve SQL Shell

For one client, I was told that our devs didn't have client access to a database with a problem, but they could connect via DBI. Thus, I whipped up the following to help them out.

It has command line history and mostly handles multi-line queries. It's not overly robust, but it's the sort of handy code you might just need in a pinch.

Perl 6 is written in... Perl 6

Today, I've done something strange.

No, there weren't drugs involved, I merely sent a patch for Rakudo for a bug I reported a few weeks back. But the patch is... interesting.

First, about the "bug." Newest JSON spec lets you have anything as the top level thing. I spotted a few modules in the Perl 6 ecosystem that still expected an object or an array only, and the vendor-specific (possibly to be made hidden in the future) to-json subroutine provided by core Rakudo behaved the same as well.

One of the modules got fixed right away and today, seeing as there were no takers, I went in to fix the bug in Rakudo myself. Since I'm a lazy bum, I merely went in to that one fixed module and just copied the fix over!

But wait a second... ain't the Perl 6 module written in Perl 6? How did I manage to "just copy it over"? What sorcery is this! Surely you lie, good sir!

Deprecation is citizenship

Last year I attended the Programming the web with Dancer master class at YAPC::NA, taught by the awesome folks Sawyer X and Mickey. It was then I learned that a new way to access get/post/route parameters was being baked and the potential pitfalls of what had been the current practice.

At the time, I was busy evangelizing the use of Dancer2 in professional work, and that meant exposing other developers at various levels of Perl familiarity how to accomplish tasks in the Dancer2 framework. While I waited for the new DSL parameter keywords be released by the Dancer2 core team, I decided to extend the Dancer2 DSL with keywords for parameter access of my own and added that to company broilerplate rather than have to worry about making sure every developer on every Dancer2 project was fully educated (or remembered) the aforementioned pitfalls when doing their work.

The Ovidian Update

Haven't posted anything for a while, but I'm not dead, just busy. Here's a quick recap of things that I think people might find of interest.

Send In The Clones (click for larger version)

First and foremost, I'm going to be in Brussels, Belgium, next weekend for FOSDEM. If you can make it, check out the Perl track. I'll be speaking about why people are finding Perl 6 so exciting. In particular, ever since the Christmas release, there's been a fair amount of chatter about Perl 6 and I've been paying a lot of attention to people who are looking at it for the first time, without a lot of preconceived notions. The reactions often range from "wow, that's cool", to "oh my goodness, I want that!" What's even more interesting is that they're not focusing on a particular feature (which would be scary as it would pigeonhole Perl 6 as a "niche" language). Instead, plenty of people getting excited about different things which scratch their particular programming fetishes: grammars, gradual typing, concurrency, and so on. It's fun to watch.

But there's more ...

About blogs.perl.org

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 hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.