[prev] [thread] [next] [lurker] [Date index for 2003/04/01]
On Tue, Apr 01, 2003 at 06:59:26AM +0100, Simon Wistow wrote:
> On Mon, Mar 31, 2003 at 02:16:01PM +0100, Richard Clamp said:
> >
> > =head2 decide what to do about $Plugin::DESCRIPTION;
> >
> > it's a bit of a sore thumb now that everything else is very OO, maybe
> > provide it as $class->description, or part of $class->options (maybe
> > with a rename to $class->options)
>
> I think putting it in $class->options is a bad idea because you're
> arbitarily preventing a plugin from having an option called description.
> Not a big deal but it's just messy.
I think one step faster than that:
$plugin->meta->{description}
$plugin->meta->{options}{$option}
Which is why I mentioned renaming ->options, as it wouldn't just be
for options any more.
> I think $class->description();
>
> Now whether we do it by automatically looking for $DESCRIPTION or just
> forcing them to write
>
> sub description { "My description here" }
>
> is left up to the list to decide.
The latter. Until we hit CPAN (which raises questions for another
time) all the apis are flexible where improvements can be made.
> > $class->require;
> >
> > which seems at little clearer
>
> Forgive my addled brain (I curse you Insomnius, Evil Lord of NoSleep)
> but does this still require (no pun intended) an eval
>
> eval {
> $class->require;
> };
>
> etc etc
I guess you later found this part of the UNIVERSAL::require docs:
Should the module require fail, or not be a high enough $version,
it will simply return false and not die. The error will be in
$UNIVERSAL::require::ERROR.
--
Richard Clamp <richardc@xxxxxxxxx.xxx>
There's stuff above here
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52