Professional Web Applications Themes

On import v. Just Do It. - PERL Beginners

p0: yes, one can use an import() from a package to make something like the scam of 'require in line' 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 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. 1.c: the count ...

  1. #1

    Default On import v. Just Do It.



    p0: yes, one can use an import() from a package
    to make something like the scam of 'require in line'
    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

    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.

    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.

    p2: clearly the fact has been established that it can be done,
    but it also notes the 'and you want this pain why?' problem....

    ciao
    drieux

    ---

    Drieux Guest

  2. #2

    Default RE: On import v. Just Do It.

    > 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?
    > 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

    > 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?
    >
    > 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 talkking 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 thae 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.
    >
    > 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...

    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 warnigns and no strict.. But why would you do that?

    Thanks

    Dan
    > ciao
    > drieux
    >
    > ---
    >
    >
    > --
    > To unsubscribe, e-mail: [email]beginners-unsubscribeperl.org[/email]
    > For additional commands, e-mail: [email]beginners-helpperl.org[/email]
    <http://learn.perl.org/> <http://learn.perl.org/first-response>


    Dan Muey Guest

  3. #3

    Default Re: On import v. Just Do It.

    Oops left out a sentence....
    > 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?
    > 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

    > 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?
    >
    > 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.
    >
    > 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...

    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?

    Thanks

    Dan
    > ciao
    > drieux
    Dan Muey Guest

  4. #4

    Default Re: On import v. Just Do It.


    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>

    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';

    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.....
    >> 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

    .....
    >> 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....

    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

    ---

    Drieux Guest

  5. #5

    Default RE: On import v. Just Do It.

    > 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 doentation (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


    Dan Muey Guest

Similar Threads

  1. dll import
    By Jason in forum ASP.NET Web Services
    Replies: 2
    Last Post: March 29th, 12:17 AM
  2. SWF import ID3.1
    By decorix29@adobeforums.com in forum Adobe Indesign Windows
    Replies: 5
    Last Post: June 27th, 11:15 AM
  3. hoq to import a gif
    By Ferdynandus webforumsuser@macromedia.com in forum Macromedia Freehand
    Replies: 0
    Last Post: November 25th, 09:33 AM
  4. No CDR Import?
    By Linda Rathgeber in forum Macromedia Fireworks
    Replies: 0
    Last Post: September 18th, 10:57 PM
  5. CSV import
    By Jwulff in forum PHP Development
    Replies: 0
    Last Post: July 21st, 05:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139