Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Extra strict subs

by Elian (Parson)
on Nov 26, 2002 at 22:10 UTC ( [id://215950]=perlmeditation: print w/replies, xml ) Need Help??

Through the generosity of Tom Phoenix, I'm in a position to take a few days and write an extra-strict version of use strict qw(subs), one that will explicitly yell at compile time if you've used a sub in your program that doesn't actually exist. I figured before I started in, I'd solicit some opinions on how it should look and behave.

The current restrictions are:

  1. Can't actually ride on use strict. (Though I may steal some bits in $^H)
  2. Must be lexically scoped
  3. Doesn't have to be backwards compatible, though that'd be nice. (perl 5.8.1 would be OK if I can convince Jarkko to put the patches in if it needs them)
  4. Shouldn't require forward declarations
  5. Doesn't have to be 100% accurate though that'd be nice1
So, anyone got any suggestions for features, or questions?

1By this I mean that, if we have to go with source filters, we don't have to catch every bizarre way to invoke subs that there are--this shouldn't yell in cases where it can't be sure

Replies are listed 'Best First'.
Re: Extra strict subs
by Louis_Wu (Chaplain) on Nov 26, 2002 at 23:10 UTC
    Your point (3) Doesn't have to be backwards compatible seems curious. How much work is it to make something of this nature compatible with 5.6, or 5.005? Would backward compatiblity require more flexibility with (5), level of accuracy?

    Does (2) mean that the tested subs have to be lexically scoped, or that the pragma must be lexically scoped?

      Point 3 means that if I have to go and modify toke.c, perly.y, and various bits of gv.c (for example) to make this work reasonably well, thus making it work only for versions of perl with the mods (likely 5.8.1 and up) that's OK. I'd rather not have to, if for no other reason than to avoid messing around in toke.c, but...

      Point 2 means that the pragma must be lexically scoped. It should only complain about uses of undefined subs in the blocks that it is in force for, so it doesn't complain about modules and whatnot that might otherwise trigger the warnings. Much of the perl library uses subs that only exist on particular platforms, with $^O conditional tests to make sure they don't get tripped over otherwise. We don't want to yell about those, nor modify the standard modules to be completely sub-safe.

        Modifying toke.c, and perly.y for a feature in a maintenance release? I sure hope Jarkko won't put that in. New development belongs in the development track - not the maintenance one.

        And I'd expect strong opposition from p5p if this extra strictness gets turned on by use strict;.

        Abigail

        Thanks. I hadn't thought about restricting the check to certain blocks, that makes sense. Not breaking CPAN is a Good Thing®.

        About modifying the compiler (which is what I assume you meant, refering to toke.c, etc), when strict was originally introduced, were compiler mods needed?

        BTW, what is the current behavior of strict in regard to nonexistant subs?

      Does (2) mean that the tested subs have to be lexically scoped, or that the pragma must be lexically scoped?

      That the updated pragma must behave like the current version; i.e:

      use strict; { no strict subs; print hi; }

      Perl 5 does not have lexically scoped subs; although perl 6 will.

        Right. We are, though, talking perl 5 stuff here, despite my other affiliations. :)
Re: Extra strict subs
by theorbtwo (Prior) on Nov 27, 2002 at 01:47 UTC

    Does this have to be a normal-use thing, like use strict, or could it be a -MO=Lint thing? (IE a slow check that you do occasionaly.) The former's going to be a lot harder then the later... I'm not even sure if it's really possible... perl's a damn dynamic language. It'd rule out AUTOLOAD tricks, imported subs (?), all sorts of other stuff...


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      A normal use thing, like use strict. Yes, it would mean that you couldn't play some of the fancier tricks but, well, too bad, that's what you asked for when you used the pragma. :)

      if I do it right, it won't stop imported subs, nor subs you declare but don't define, so you can AUTOLOAD later. You'll have to have a "sub foo;" somewhere, to make sure the foo sub's noted, but that's fine.

      I expect this will end up tallying the subs that are used in the blocks that it's in force, then at CHECK time making sure there are entries in the GV slot of the appropriate symbol table entries, but as I said I've not nailed down exactly how it'll behave yet.

        Sounds like it'll work. It'd be nice, however, to be able to say use strict; no strict 'super-subs'; or somthing to get existing use strict 'subs' behivor, but not the new behavor.


        Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: Extra strict subs
by demerphq (Chancellor) on Nov 27, 2002 at 12:34 UTC
    By this I mean that, if we have to go with source filters, we don't have to catch every bizarre way to invoke subs that there are--this shouldn't yell in cases where it can't be sure

    Id like an option to make it yell if it isn't sure. Other than that this sounds like a great idea. Thanks.

    (Although personally I would be a million times happier if the Assert patch proposed to p5p recently got implemented instead...) (er i am aware that beggars can't be choosers, its just that the assertion idea would be a very welcome and useful tool in what I am working on right now :-)

    --- demerphq
    my friends call me, usually because I'm late....

Re: Extra strict subs
by Anonymous Monk on Feb 15, 2013 at 09:38 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://215950]
Approved by Mr. Muskrat
Front-paged by thraxil
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (6)
As of 2024-03-19 02:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found