> On Jan 20, 2004, at 9:19 AM, Dan Muey wrote:
>
> > Oops left out a sentence....
>
> sorry for the delay.
>
> >> p0: yes, one can use an import() from a package
> >> to make something like the scam of 'require in line'
> >
> > Why is it a scam if that's what I want to do for myself?
>
> I presume we are talking about
> <http://www.nntp.perl.org/group/perl.beginners/58676>
>
> eg:
> > package Foo::Monkey;
> > sub import {
> > for my $pragma (qw(strict warnings)) {
> > require "$pragma.pm";
> > $pragma->import;
> > }
> > }
>
> which does have the technical nit that it did not
> end with
> 1;
>
> so is not really ready to be rolled up as a perl module.
> cf:
> <http://www.nntp.perl.org/group/perl.beginners/58551>
Yes
>
> rather than starting with a code template of
>
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> So the idea of learning about how to do an 'import' is
> a worthwhile crusade in itself. I'm just not convinced
> that it really has the voodoo one would want since it
> of course is doing the obligatory two step of first
> requiring the pragma and then invoking it's import method...
>
> cf the distinctions between 'require' and 'use'.
>
> So my notion of 'scam' derives from the politer approach
> to the comedy of someone coming up with a Way to solve a
> problem that seems fundamentally structurally more complex
> than the problem that it is trying to solve.
>
> >> for the twin pragma of 'use strict' and 'use warnings'
> >> { oye! }
> >>
> >> p1: But there is this minor technical overhead that
> >> comes with the process -
> >>
> >> 1.a: one needs to use h2xs to make sure that the
> >> module will conform with the current best practices
> >> and be appropriately installable in the CPAN way
> >>
> > my module or strict and warnings?
> > One would assume the the developer has a responsibility
> > to make their code solid and as compatible and
> compliant as possible
>
> oh quite right. So why would one want to add in a
> module that had merely the importing of the two lines
> that are pragma?????
>
> which is the target of my rant. I of course would not
> feel morally upright if I had constructed a perl module
> that did not contain
>
> a. the version of perl that was my minimum to bid
> use 5.006001;
> b. the canonical brace of caution:
> use strict;
> use warnings;
> c. the version value:
> our $VERSION = '1.3';
You forgot c.1:
sub VERSION { return $VERSION; }
of course sub VERSION could lead to anarchy :)
and as you mentioned above:
d. 1; at the end
The target of my rant of your rant is that this is only one
little part of Foo::Monkey (actual module names have been changed
to protect the innocent), rarely does anyone need ot post the
entire code when trying to figure out a single simple solution to one issue.
And if that becomes necessary then the thread will request that eventually.
>
> The reason that I of course appeal to the h2xs approach is
> that it will include the base suite of files
>
> a. MANIFEST
> b. Makefile.PL
> c. foo.pm
> d. t/1.t
>
> So that I can have a basic framework for making sure that
> I can get the core steps done
> perl *.PL
> make
> make test
> make install
>
> So now the problem has evolved from merely two lines of
> pragma, to a minimum of four files that I need to keep
> under source code control.....
>
Except that you are assumming the module sole purpose is to do use strict and warnings
for you.
And the OP wasn't asking abou the proper way to build a module.
> >> 1.b: one has to maintain that module just to make the
> >> two lines of pragma readily available to all of one's
> >> perl code.
> >
> > If that's the point of the module and users know that,
> > isn't the maintainer supposed to, well er
> maintain it properly?
> >
> > Also wouldn't the script author have to do the
> same thing
> > except in all his scripts instead of one place?
>
> Oh yes... and that of course is where we are now up to
> the four files in the SCCS du jure, and ....
>
> >> 1.c: the count of lines of the perl module vice the
> >> simple inclusion of the two lines makes the process
> >> a bit Wonky if you know what I mean.
> >
> > Not really, if we are talking strictly line
> counts then do this:
> >
> > in 50 scripts:
> > use Foo::Monkey; = 50 lines
> > (
> > ok 100 if you count:
> > sub import {
> for('strict',warnings') { if(gotmodule($_) {
> > $_->import; } } }
> > # gotmodule is a
> function in side Foo::Monkey that basically does
> > eval("use $_[0]")
> > # and returns true if
> it was able to be loaded, it works too I
> > tested it
> > # also it avoids
> killing the script if it can't be loaded since
> > it only does $_->import
> > # if the module could be use()ed
> > )
> > you get strict and warnings
> plus the many other nifty things about
> > Foo::Monkey
> >
> > use strict;use warnings = 100 lines.
> >
> > So depending on how you look at it, there are
> less or the same
> > amount of *lines* but many more advantages as
> far as I can tell.
>
>
> We're missing the part where all perl scripts start with
>
> #!/usr/bin/perl
>
> since we can be pedantic.... 8-)
>
> But of course so far we have not included
>
> a. the POD for the module
> b. the readme and change files
Which have nothgin to do with the price of tea in China at this point right?
>
> ....
>
> >> p2: clearly the fact has been established that it can be
> done, but it
> >> also notes the 'and you want this pain why?' problem....
> >
> > I don't understand the pain you speak of, could you define more
> > clearly why I don't want to do the import() to make it automatic so
> > this module's users have to consciously turn off strict and
> warnings
> > instead of consciously turn it on like we tell people to do over an
> > over an over...
>
> Perchance this is the crucial point.
>
> If the coders in your organization are failing to do this,
> and one needs to create a perl module to wrap the pragma
> for them, perchance there is some other more pressing issue
> that really needs to be addressed?
>
> I personally support the use of Flogging Bad Coders.....
>
> > I mean as long as I make it clear, and I would definitely blab about
> > it as an advantage, that by doing
> > use Foo::Monkey;
> > # enables strict and warnings for your script for
> better scripting
> > practice!!
> > # If you don't like that use no warnings and no
> strict.. But why
> > would you do that?
>
> I don't think I will ever be able to deal with a
>
> Foo::Monkey
>
> in quite the same light ever again....
Me neither.
>
> 8-)
>
> I of course start from 'templates' of code stuff, so
> that my stock perl code comes out the door for a mere
> dull boring illustrative code as:
>
> #!/usr/bin/perl -w
> use strict;
>
> # #FILENAME# - is for
>
> so yes, technically, now that I do 5.8 I should upgrade that
> template...
>
> But IF you find that the solution of Foo::Monkey is simpler
> to implement as a corporate policy in lieu of Flogging, I
> am all the more willing to support your life style choice here...
>
> ciao
> drieux
So yes doing a module to do use strict and use warnigns
for you and that's all it does would be overkill.
But if said module had a specific development purpose, stated in
it's documentation (every part of it set up by Proper module creation
process of course), containes all the standard and proper module
goodies (from use 5.6.1; all the way down to 1;), and you want
the development environment created by this module to include as
many good practive features and solidnesses (I like my new word ;p)
as you can (IE use strict and use warnings autmatically if you'll be
developing with this module) then why not pop that in there? It's only
one extra line in my version in a module that is a few hundred or so
long. And it can always be turned off, but it will take effort to
*become* "unsafe" instead of effort to become safe.
[deep gasp for long needed breath and..]
Thanks
Dmuey
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
