Petal::Utils (was Re: [Petal] Looping through a hash)

[Steve Purkis]

On Friday, September 5, 2003, at 08:40  pm, William McKee wrote:

> On Fri, Sep 05, 2003 at 07:27:44PM +0100, Steve Purkis wrote:
>> I can do, but if you'd like to take it on you're more than welcome.
>
> Wow! Nice work. You definitely have more background with Perl and
> modules than I do, so I'm going to let you adopt this one. Maybe I'll
> get registered as a developer and upload a few new modifiers in the
> future.

Thanks for the feedback -- I'll whack it up on CPAN in a few moments 
then.  Hopefully it won't require too much work though; I'm getting 
swamped with maintenance woes as it is ;-).  Maybe when you get your 
CPAN account you can take over this module?

Also, if its alright with everyone I'll put the Petal List down as the 
place for this to be discussed.  And if other people want to contribute 
to the project, we should bung this up onto a public CVS server 
somewhere -- I'll host it locally until I hear otherwise.


> I should be able to create CPAN projects within the Petal::Util::* 
> path,
> right? I think it's important to allow anyone to be able to glob on to
> the existing pattern without needing someone's approval to include the
> package with the Petal::Util modules. However, looking at Util.pm, it
> seems to me that it would mean that we need to dynamically build the
> %PLUGIN_SET hash. Or will the user simply have to explicity request the
> module (e.g., use Petal::Utils qw(NewMod))?

Well..  I'm not 100% sure if writing additional modules outside of the 
Petal-Utils distro is a good idea.  If you do, why not just set 
%Petal::Hash::MODIFIER directly?  But to answer your question, yes 
users would have to explicitly request a module that Petal::Utils 
doesn't know about:

	use Petal::Utils qw( NewMod );

Dynamically building %PLUGIN_SET is, well, difficult.  You're basically 
asking for a plugin manager for Petal, which is not what Petal::Utils 
was meant to be.

My first reaction is to say that %PLUGIN_SET is private for a reason.  
It's hard-coded and was meant to be populated by hand.  Having said 
that, with a few small changes you could update it dynamically from 
another module, which you'd still have to use:

	use Petal::Utils::MyUtil; # add MyUtil to %PLUGIN_SET
	use Petal::Utils qw( MyUtil :default );

This would be a bit pointless for individual modules, but might be 
useful for distros containing more than one.  Still, I'd argue that you 
could just inherit from Petal::Utils and have your own %PLUGIN_SET:

	use Petal::Utils::MyUtils qw( MyUtil :my_foo ); # inherit from P:Utils
	use Petal::Utils qw( :default :foo );
	
A different way of approaching this might be to update the %PLUGIN_SET 
every time a new Petal::Utils module was installed.  This would require 
some fancy installation code, but could be done.  Though if it happens 
I'd recommend calling it something other than Petal::Utils...  
Petal::PluginManager perhaps.  And if you go to that lenght, you might 
as well look inyo integrating it with Petal.

Yet another possibility is to search @INC for plugins, just like Petal 
does.  But that seems so close to what Petal already does that it 
doesn't really make sense to duplicate the effort.

Personally, I think the plugin manager is a neat idea, but I don't see 
enough reason to write it at the moment.  I'm tempted to keep things as 
is for now.


>> Thanks for getting the ball rolling...  I've spent some time today
>> adding my 2?.  It's a bit more than 4K now, so I've put it up here:
>
> It was worth the effort looking at what has come out of it!

Glad you like it.


> I notice that you are using a function from Date::Format called 
> time2str
> in Date.pm now. I am getting a test failure as follows:
>
>> t/02__default....NOK 4#     Failed test (t/02__default.t at line 84)
>> #     doesn't match '(?-xism:date = Jan\s+1 1970 01:00:01)'
>
> The pertinent output line is:
>> date = Dec 31 1969 19:00:01
>
> It looks like the time has been offset by my localtime (GMT -4). We 
> need
> to tell Date::Format to assume that localtime is being passed in to the
> time2str function.

Quite right, but I think it's a problem with the tests more than 
anything else.  I get GMT +1, which is the standard behaviour of 
Date::Format.  We could stick in an optional $TIMEZONE class var if 
this is a problem in the templates, but for now I'll just make that 
test more generic.

-Steve