Modules & Limitations

barbie on 2003-05-12T13:43:56

I have been busy working on Calendar::List this weekend and having written the tests first (do i get a star ;) ), I attempted a first 'make test'. Apart from a few obvious things I'd missed, the test showed the limitation of timelocal() in Time::Local. timelocal() is used in Dave Cross's module Calendar::Simple, which mine uses to get a monthly listing. Unfortunately on 32 bit systems the dreaded Jan 2038 limitation rears its head. Thankfully, Date::ICal doesn't suffer with this, so I've made a quick fix to Dave's module, which hopefully he'll be able to implement in a forthcoming release.

As a consequence of my testing I also realised that my naive method of copying a hash to a hash, was a bit flaw. Okay, a lot flawed. I had a quick look on CPAN and found the funky Clone, which does exactly what I want ... yea :) It now means I can set up a nice defaults hash, and copy that each time I start a new list. I may not use it in the long term, but it does the job while I finish off the other bits.

While looking at the recently uploaded modules list, I also spotted a nice little module, Params::Check. I'm a little bit gutted as I have been implementing something similar for sometime, but never thought to wrap it up into a nice neat module for CPAN. The module extends beyond my code, so I'm hoping to incorporate the module into my apps. However, I do have some misgivings.

Params::Check will do the following things for you:
  • Convert all keys to lowercase
  • Weed out arguments that are not supported and warn about them to the user


The first is a little presumptuous. I use UPPER, Mixed and lower case parameter names to indicate different things, having them forced to lower case is not a good one. It should be up to the user. I suggest another global variable of $Params::Check::TO_LOWER.

The second again assumes you must have warnings. I always thought warnings, by their very nature, were an optional thing. So why again force the user to handle them. The default should be to ignore warnings and let the user decide if they want them or not.

In addition I also have some paramater names, which have a suffix corresponding to a numeric id. It would be nice to have another key rule (along the lines of 'allow') for 'suffix'.

I have emailed Jos with my suggestions, so I'll wait and see whether he thinks they're worth adding. If I have time I will try and write a patch, but certainly for this week, thats doubtful. Though having said all that, I do think think this has the makings of a well used module.

It wasn't my intention when I started this entry, but I think this is the most hyperlinked entry I've written. Perhaps I should calm down now.


dclone

2shortplanks on 2003-05-12T14:59:08

I'd be tempted to use Storable's dclone rather than Clone.pm. Storable's core now (well, since 5.8.X) so it's likely people will have it installed. The other annoying thing about Clone is that it's an XS module (it has to be, to be the blindingly fast code it is) so it's a pain for Windows users to install.

Re:dclone

barbie on 2003-05-12T15:43:44

I was going to use dclone, but the POD in Storable.pm recommended using Clone.pm. I'm only using it temporarily while I get round to doing other things, before using a better method. So it probably won't be in the final version.

However, I suspect most will install on Windows via PPM and ActiveState have a version in their repository. So probably not as bigger pain as you might think :) Certainly installed on my Win2K box in a few seconds.