RE: possible RFC?
On Wed, 2002-08-14 at 15:43, Nikola Janceski wrote: > Okay I understand the dynamic subroutine declarations. > but perhaps a warning should be made for -w or 'use warnings'? > > It's just to find misspelled functions. I use 'use strict' for finding > misspelled vars. > Is there nothing for finding misspelled functions, aside from running it and > hoping for the best? > > Nikola Janceski > > What counts is not necessarily the size of the dog in the fight - it's the > size of the fight in the dog. > -- Dwight D. Eisenhower > > > > > The views and opinions expressed in this email message are the sender's > own, and do not necessarily represent the views and opinions of Summit > Systems Inc. This is what Symbol::Approx::Sub is for . http://search.cpan.org/author/DAVECROSS/Symbol-Approx-Sub-2.00/Sub.pm";> DESCRIPTION This is _really_ stupid. This module allows you to call subroutines by _approximate_ names. Why you would ever want to do this is a complete mystery to me. It was written as an experiment to see how well I understood typeglobs and AUTOLOADing. To use it, simply include the line: use Symbol::Approx::Sub; somewhere in your program. Then each time you call a subroutine that doesn't exist in the the current package Perl will search for a subroutine with approximately the same name. The meaning of 'approximately the same' is configurable. The default is to find subroutines with the same Soundex value (as defined by Text::Soundex) as the missing subroutine. There are two other built-in matching styles using Text::MetaPhone and String::Approx. -- Today is Boomtime the 8th day of Bureaucracy in the YOLD 3168 Umlaut Zebra über alles! Missile Address: 33:48:3.521N 84:23:34.786W -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible RFC?
Nikola Janceski wrote:
> WTF doesn't perl -c check for valid subroutines/function calls?
>
> I can write a perlscript calling a function that doesn't exist but perl -c
> will say syntax ok.
> ie:
> % perl -ce "nothing_here('some junk')"
> -e syntax OK
>
> % perl -e "nothing_here('some junk')"
> Undefined subroutine &main::nothing_here called at -e line 1.
>
> That doesn't make sense!
> It should check function calls at compile time, correct?
> So why not for -c?
I'd hazard a guess it's to do with it sometimes being hard to tell if a
function does exist or not at compile time. Think AUTOLOAD and string eval.
Thanks,
Daniel
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible RFC?
> "Adam" == Adam Turoff <[EMAIL PROTECTED]> writes: Adam> On Wed, Aug 14, 2002 at 02:53:49PM -0400, Nikola Janceski wrote: >> WTF doesn't perl -c check for valid subroutines/function calls? Adam> Because it's quite possible to define subs dynamically. That is, Adam> the sub isn't defined directly in your code, but is created (and Adam> installed) after your code has started execution. This is a Adam> frequently used technique in some kinds of development. Look into Adam> AUTOLOAD for more details. Or even "require". And that's pretty durn frequent. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: possible RFC?
On Aug 14, Nikola Janceski said: >Okay I understand the dynamic subroutine declarations. >but perhaps a warning should be made for -w or 'use warnings'? > >It's just to find misspelled functions. I use 'use strict' for finding >misspelled vars. Is there nothing for finding misspelled functions, aside >from running it and hoping for the best? I have some work on that. I'll post it when I'm done. -- Jeff "japhy" Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/ RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/ ** Look for "Regular Expressions in Perl" published by Manning, in 2002 ** what does y/// stand for? why, yansliterate of course. [ I'm looking for programming work. If you like my work, let me know. ] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: possible RFC?
Okay I understand the dynamic subroutine declarations. but perhaps a warning should be made for -w or 'use warnings'? It's just to find misspelled functions. I use 'use strict' for finding misspelled vars. Is there nothing for finding misspelled functions, aside from running it and hoping for the best? Nikola Janceski What counts is not necessarily the size of the dog in the fight - it's the size of the fight in the dog. -- Dwight D. Eisenhower The views and opinions expressed in this email message are the sender's own, and do not necessarily represent the views and opinions of Summit Systems Inc. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: possible RFC?
> -Original Message-
> From: Nikola Janceski [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 14, 2002 2:54 PM
> To: Beginners (E-mail)
> Subject: possible RFC?
>
>
> WTF doesn't perl -c check for valid subroutines/function calls?
>
> I can write a perlscript calling a function that doesn't
> exist but perl -c
> will say syntax ok.
> ie:
> % perl -ce "nothing_here('some junk')"
> -e syntax OK
>
> % perl -e "nothing_here('some junk')"
> Undefined subroutine &main::nothing_here called at -e line 1.
>
> That doesn't make sense!
> It should check function calls at compile time, correct?
No, otherwise CGI.pm and tons of other stuff would never work.
> So why not for -c?
Consider the following program:
$_ = 'sub foo { print "Hello World\n" }';
eval $_;
foo();
foo() is not defined a compile-time, but it's still a perfectly valid
program. Because of this, perl -c cannot check the call to foo() at
compile-time.
Thinking of perl -c as a "compiler" is a bit of a misnomer. Just for kicks,
wrap the code above in a BEGIN { } block and run perl -c on it. See what I
mean?
>
> Excuse me if I have overstepped my bounds. I still love Perl
> regardless, but
> it can be better.
No way! :~)
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible RFC?
On Wed, Aug 14, 2002 at 02:53:49PM -0400, Nikola Janceski wrote: > WTF doesn't perl -c check for valid subroutines/function calls? Because it's quite possible to define subs dynamically. That is, the sub isn't defined directly in your code, but is created (and installed) after your code has started execution. This is a frequently used technique in some kinds of development. Look into AUTOLOAD for more details. Z. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible RFC?
One reason is that you can make runtime use/require calls, as well as
run-time function definitions with eval.
For example
use strict;
my $subname = 'contrived';
eval qq(sub $subname { print "This could be useful\n" });
contrived();
This may seem highly contrived (it is), but there are useful examples of
this as well, for instance in making factory classes.
George
Nikola Janceski wrote:
>WTF doesn't perl -c check for valid subroutines/function calls?
>
>I can write a perlscript calling a function that doesn't exist but perl -c
>will say syntax ok.
>ie:
>% perl -ce "nothing_here('some junk')"
>-e syntax OK
>
>% perl -e "nothing_here('some junk')"
>Undefined subroutine &main::nothing_here called at -e line 1.
>
>That doesn't make sense!
>It should check function calls at compile time, correct?
>So why not for -c?
>
>Excuse me if I have overstepped my bounds. I still love Perl regardless, but
>it can be better.
>
>Nikola Janceski
>
>The significant problems we face today cannot be solved at the same level of
>thinking we were at when we created them.
>-- Albert Einstein (1879-1955)
>
>
>PS. I still drool over the apocalypse papers on Perl 6. I can't wait!
>
>
>
>The views and opinions expressed in this email message are the sender's
>own, and do not necessarily represent the views and opinions of Summit
>Systems Inc.
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
