Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > calling subroutine , name derived from variable

Reply
Thread Tools

calling subroutine , name derived from variable

 
 
Theo van den Heuvel
Guest
Posts: n/a
 
      01-06-2006
<robic0> schreef in bericht
news:(E-Mail Removed)...
> Don't ever, ever take any class I teach...


It took me a while to recover from this. I think a gentle hint
is called for. You shouldn't teach. You shouldn't teach, because
you suffer from a disposition for which, if I recall correctly,
the official medical term is stupidity. Not a mild form of it,
but the rarest variety of unmitigated, terminal stupidity.
You have proven this time and again. As a recent example,
I remember your rants on parsing when you tried to tackle
XML with regexes. So I urge you: do consider your pupils.
They might learn something from you. You should definitely
not teach.


 
Reply With Quote
 
 
 
 
ced@carios2.ca.boeing.com
Guest
Posts: n/a
 
      01-06-2006

http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
.....
> Try:
>
> #!/usr/local/bin/perl
>
> use strict;
> use warnings;
>
> my $method="aSub";
> my $aa= 'bla';
>
> no strict;

^^^^^^^^^^^

I've forgotten where I saw the doc ref. but the &$method
call is ignored by 'strict' so you don't even need 'no strict'.

> my $ret = eval(&$method ($aa));
> ...


hth,
--
Charles DeRykus

 
Reply With Quote
 
 
 
 
Samwyse
Guest
Posts: n/a
 
      01-07-2006
Tad McClellan wrote:
> Madhu Ramachandran <(E-Mail Removed)> wrote:
>
>>Thank you very much for the help.

>
> You are not fooling anyone.
>
> If you truly were thankful, then you would follow the quoting
> conventions that folks expect here (and nearly everywhere else too).


I personally consider top-posting forgivable for a simple thank-you,
since the preceding conversational context isn't needed to understand
what's going on.

Full-quoting, OTOH, is definitely evil.
 
Reply With Quote
 
Samwyse
Guest
Posts: n/a
 
      01-07-2006
(E-Mail Removed) wrote:

> no strict;
> my $ret = eval(&$method ($aa));
>
> use strict;


Or even (arguably) better:

my $ret = do { no strict; eval(&$method ($aa)); };
 
Reply With Quote
 
Eric J. Roode
Guest
Posts: n/a
 
      01-07-2006
(E-Mail Removed) wrote in
news:Ttxvf.21305$(E-Mail Removed). uk:

> Try:
>
> #!/usr/local/bin/perl
>
> use strict;
> use warnings;
>
> my $method="aSub";
> my $aa= 'bla';
>
> no strict;
> my $ret = eval(&$method ($aa));
>
> use strict;
> print "ret = ", $ret "\n";
>
> sub aSub() {
> my $arg1 = shift;
> print "inside aSub, arg1=", $arg1, "\n");
> return 1;
> }



Did *you* try it?

Please, don't post code unless you really know that it works.
Test first.

--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
 
Reply With Quote
 
Brian McCauley
Guest
Posts: n/a
 
      01-08-2006
Matt Garrish wrote:

> You're looking for symbolic references, but it's not good practice to use
> them. For example:
>
> $subRef = 'this_sub';
> $arg1 = 'first argument';
> $arg2 = 'second argument';
>
> &{$subRef}($arg1, $arg2);
>
> sub this_sub {
> print "$_[0] : $_[1]\n";
> }
>
>
> It's better practice to use a hash as you won't break the strictures pragma
> that way, which should make your code easier to maintain:


Beware the knee-jerk anti-symref reaction.

There are a lot of things wrong with using symbolic references, but
many of perfectly valid arguments against using symbolic references
simply don't apply in the context of symbolic code references. Indeed
Perl's own version of OO is effectively implemented using symbolic code
referecence.

It is often good practice to place all the subroutines you want to use
into a package that is used for nothing else. Doing so negates the two
major problems with using symrefs (security and conceptual code/data
separation)..

my $subRef = 'this_sub';

my $arg1 = 'first argument';
my $arg2 = 'second argument';

# Use a symref one way...
(\&{"My:ispach:ackage::$subRef"})->($arg1, $arg2);

# ... or another
{
no strict 'refs';
"My:ispach:ackage::$subRef"->($arg1, $arg2);
}

sub My:ispach:ackage::this_sub {
print "$_[0] : $_[1]\n";
}

 
Reply With Quote
 
Matt Garrish
Guest
Posts: n/a
 
      01-09-2006

"Brian McCauley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> Matt Garrish wrote:
>
>
> It is often good practice to place all the subroutines you want to use
> into a package that is used for nothing else. Doing so negates the two
> major problems with using symrefs (security and conceptual code/data
> separation)..
>
>
> # Use a symref one way...
> (\&{"My:ispach:ackage::$subRef"})->($arg1, $arg2);
>
> # ... or another
> {
> no strict 'refs';
> "My:ispach:ackage::$subRef"->($arg1, $arg2);
> }
>


The latter has actually become my preferred choice for calling functions
based on a parameter passed to a script, but I expected that advocating it
would just lead to an endless discussion of the evils of symrefs. Nice to
see I'm not the only one...

Matt


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Variable variable name" or "variable lvalue" mfglinux Python 11 09-12-2007 03:08 AM
Derived::Derived(const Base&) and Derived& operator=(const Base&) developereo@hotmail.com C++ 1 05-23-2007 01:44 PM
Derived::Derived(const Base&) and Derived& operator=(const Base&) developereo@hotmail.com C++ 1 05-23-2007 12:07 AM
use one subroutine's variable value in another subroutine inside a module. king Perl Misc 5 04-29-2007 06:39 AM
adding a variable name to a hash to name is part of the variable name Bobby Chamness Perl 2 04-22-2007 09:54 PM



Advertisments