how to call sub by value in variable

I have this simple script

#!/usr/bin/perl
use strict;

foreach my $sub (qw/test1 test2/)
{
foreach my $name (qw/Petr John/)
{
no strict 'refs';
&$sub($name);
}
}

sub test1
{
my $txt=shift;
print "Hallo $txt\n";
}

sub test2
{
my $txt=shift;
print "Bye $txt\n";
}

I use no strict 'refs' and it work fine, but how to write this with strict
refs? It is possible? I need to use it first time in my live and reason is
that subroutine names (in real script) are stored in MySQL.
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: how to call sub by value in variable

"Petr Vileta" wrote:
> I have this simple script
>
> #!/usr/bin/perl
> use strict;
>

my %dispatch = ( test1 => \&test1, test2 => \&test2);

> foreach my $sub (qw/test1 test2/)
> {
> foreach my $name (qw/Petr John/)
> {

$dispatch{$sub}->($name);

> }
> }
....
>
> I use no strict 'refs' and it work fine, but how to write this with
> strict refs? It is possible? I need to use it first time in my live and
> reason is that subroutine names (in real script) are stored in MySQL.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: how to call sub by value in variable

xhoster@gmail.com wrote:
> "Petr Vileta" wrote:
>> I have this simple script
>>
>> #!/usr/bin/perl
>> use strict;
>>
>
> my %dispatch = ( test1 => \&test1, test2 => \&test2);
>
>> foreach my $sub (qw/test1 test2/)
>> {
>> foreach my $name (qw/Petr John/)
>> {
>
> $dispatch{$sub}->($name);
>
>> }
>> }
> ...
>>
>> I use no strict 'refs' and it work fine, but how to write this with
>> strict refs? It is possible? I need to use it first time in my live
>> and reason is that subroutine names (in real script) are stored in
>> MySQL.
>
Hmm, very nice ;-) By your solution I must define $dispatch{...} for all my
subs. Of course it is correct practice but I get sub's names from database.
If I get sub name which not exist then my script write something into system
log file but still run and call other subs which exists.

So I see I must write other example. Not with using database but using text
files. Please can you make changes to this example? Please keep in mind that
these text files are generated out of my control. My idea is that when my
script get sub name which exist then call this, in other case generate some
error but continue run.

--- file routines.txt ---
test1
test1a
test2
---------------------------

--- file names.txt ---
Petr
John
--------------------------

#!/usr/bin/perl
use strict;

open IN,"routines.txt";
my @roitines=;
close IN;
open IN,"names.txt";
my @names=;
close IN;
foreach my $sub (@routines)
{
foreach my $name (@names)
{
no strict 'refs';
&$sub($name);
}
}

sub test1
{
my $txt=shift;
print "Hallo $txt\n";
}

sub test2
{
my $txt=shift;
print "Bye $txt\n";
}

--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: how to call sub by value in variable

"Petr Vileta" wrote:
> xhoster@gmail.com wrote:
> > "Petr Vileta" wrote:
> >> I have this simple script
> >>
> >> #!/usr/bin/perl
> >> use strict;
> >>
> >
> > my %dispatch = ( test1 => \&test1, test2 => \&test2);
> >
> >> foreach my $sub (qw/test1 test2/)
> >> {
> >> foreach my $name (qw/Petr John/)
> >> {
> >
> > $dispatch{$sub}->($name);
> >
> >> }
> >> }
> > ...
> >>
> >> I use no strict 'refs' and it work fine, but how to write this with
> >> strict refs? It is possible? I need to use it first time in my live
> >> and reason is that subroutine names (in real script) are stored in
> >> MySQL.
> >
> Hmm, very nice ;-) By your solution I must define $dispatch{...} for all
> my subs.

Just for all of the ones you want to be runnable based on data from the
database!

> Of course it is correct practice but I get sub's names from
> database. If I get sub name which not exist

What do you use to know that it does not exist? What if it does exist,
it just isn't a sub you want to be run based on data retrieved from
the database?

> then my script write
> something into system log file but still run and call other subs which
> exists.
>
> So I see I must write other example. Not with using database but using
> text files. Please can you make changes to this example? Please keep in
> mind that these text files are generated out of my control.

It seems to me to be very dangerous to run subroutines whose names are
based on things generated beyond your control. But, if you are quite
certain that that is what you want to do, then turning of strict the way
you did in you example seems to be way to do it.

In other words, since what you want to do fundamentally violates the spirit
of "use strict", the most straightforward way to do it is to turn off
strict for that block.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: how to call sub by value in variable

Petr Vileta wrote:
> I get sub's names from
> database. If I get sub name which not exist then my script write
> something into system log file but still run and call other subs which
> exists.

Why would that prevent you from using a dispatch table instead of
playing with symrefs?

> So I see I must write other example. Not with using database but using
> text files. Please can you make changes to this example? Please keep in
> mind that these text files are generated out of my control. My idea is
> that when my script get sub name which exist then call this, in other
> case generate some error but continue run.
>
> --- file routines.txt ---
> test1
> test1a
> test2
> ---------------------------
>
> --- file names.txt ---
> Petr
> John
> --------------------------
>
> #!/usr/bin/perl
> use strict;

use warnings;

my %dispatch = ( test1 => \&test1, test2 => \&test2 );

open my $routines, '<', 'routines.txt' or die $!;
open my $names, '<', 'names.txt' or die $!;
chomp( my @names = <$names> );

while ( my $sub = <$routines> ) {
chomp $sub;
unless ( $dispatch{$sub} ) {
print "Function '$sub' not found\n";
next;
}
$dispatch{$sub}->($_) for @names;
}

> sub test1
> {
> my $txt=shift;
> print "Hallo $txt\n";
> }
>
> sub test2
> {
> my $txt=shift;
> print "Bye $txt\n";
> }

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Re: how to call sub by value in variable

On Sun, 19 Aug 2007 04:28:25 +0200, "Petr Vileta"
wrote:

>> my %dispatch = ( test1 => \&test1, test2 => \&test2);
>>
>>> foreach my $sub (qw/test1 test2/)
>>> {
>>> foreach my $name (qw/Petr John/)
>>> {
>>
>> $dispatch{$sub}->($name);
[snip]
>Hmm, very nice ;-) By your solution I must define $dispatch{...} for all my
>subs. Of course it is correct practice but I get sub's names from database.
>If I get sub name which not exist then my script write something into system
>log file but still run and call other subs which exists.

my $code=$dispatch{$sub};
if (defined $code) {
Log "'$sub' does not exist";
} else {
$code->($name);
}


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: how to call sub by value in variable

On 08/18/2007 07:56 PM, Petr Vileta wrote:
> I have this simple script
>
> #!/usr/bin/perl
> use strict;
>
> foreach my $sub (qw/test1 test2/)
> {
> foreach my $name (qw/Petr John/)
> {
> no strict 'refs';
> &$sub($name);
> }
> }
>
> sub test1
> {
> my $txt=shift;
> print "Hallo $txt\n";
> }
>
> sub test2
> {
> my $txt=shift;
> print "Bye $txt\n";
> }
>
> I use no strict 'refs' and it work fine, but how to write this with
> strict refs? It is possible? I need to use it first time in my live and
> reason is that subroutine names (in real script) are stored in MySQL.

You can keep strict refs enabled if you are willing to turn the
subroutines into methods:

#!/usr/bin/perl
use strict;
use warnings;

foreach my $sub (qw/test1 test2/)
{
foreach my $name (qw/Petr John/)
{
__PACKAGE__->$sub($name);
}
}

sub test1
{
shift;
my $txt=shift;
print "Hallo $txt\n";
}

sub test2
{
shift;
my $txt=shift;
print "Bye $txt\n";
}

__END__

This can still be dangerous I think, so validate your input before
calling the methods. It's better to just use a dispatch table as the
others said.

Re: how to call sub by value in variable - SOLVED

My final solution. Maybe is possible to write it without using eval() ???

--------- CUT --------
#!/usr/bin/perl
use strict;
use warnings;

my %dispatch;
open IN,"< $0";
while()
{
chomp;
if(m/^sub\s+ex_([^\s\{]+)/)
{
eval('$dispatch{' . $1 . '} = \&ex_' . $1);
}
}
close IN;
foreach my $sub (qw/test1 test3 test2/)
{
foreach my $name (qw/Petr John/)
{
if(defined $dispatch{$sub}) {$dispatch{$sub}->($name);}
else {warn "Sub '$sub' not defined\n";}
}
}

sub ex_test1
{
my $txt=shift;
print "Hallo $txt\n";
}

sub ex_test2
{
my $txt=shift;
print "Bye $txt\n";
}
--------- CUT --------

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: how to call sub by value in variable - SOLVED

On Aug 19, 3:46 pm, "Petr Vileta" wrote:
> My final solution. Maybe is possible to write it without using eval() ???

Yes, use symbolic references! There is nothing that can be achieved
with symbolic references that can't be done worse using eval(). But be
in no doubt - replacing symbolic references with eval() is (usually)
making matters worse not better.

> --------- CUT --------
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> my %dispatch;
> open IN,"< $0";
> while()
> {
> chomp;
> if(m/^sub\s+ex_([^\s\{]+)/)
> {
> eval('$dispatch{' . $1 . '} = \&ex_' . $1);
> }}

You are loosing sight of the objective. You seem to want to use the
Perl symbol table itself as your dispatch table. You should either
stop wanting to do this or you should just go ahead and use symbolic
references. There's no point making things more complex.

Re: how to call sub by value in variable

On Aug 19, 9:36 am, "Mumia W." +nos...@earthlink.net> wrote:
> On 08/18/2007 07:56 PM, Petr Vileta wrote:
>
>
>
> > I have this simple script
>
> > #!/usr/bin/perl
> > use strict;
>
> > foreach my $sub (qw/test1 test2/)
> > {
> > foreach my $name (qw/Petr John/)
> > {
> > no strict 'refs';
> > &$sub($name);
> > }
> > }
>
> > sub test1
> > {
> > my $txt=shift;
> > print "Hallo $txt\n";
> > }
>
> > sub test2
> > {
> > my $txt=shift;
> > print "Bye $txt\n";
> > }
>
> > I use no strict 'refs' and it work fine, but how to write this with
> > strict refs? It is possible? I need to use it first time in my live and
> > reason is that subroutine names (in real script) are stored in MySQL.
>
> You can keep strict refs enabled if you are willing to turn the
> subroutines into methods:
>
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> foreach my $sub (qw/test1 test2/)
> {
> foreach my $name (qw/Petr John/)
> {
> __PACKAGE__->$sub($name);
> }
> }
>
> sub test1
> {
> shift;
> my $txt=shift;
> print "Hallo $txt\n";
>
> }
>
> sub test2
> {
> shift;
> my $txt=shift;
> print "Bye $txt\n";
>
> }
>
> __END__
>
> This can still be dangerous I think, so validate your input before
> calling the methods.

Indeed it is more dangerous than explicit symbolic CODE refs because
unlike putting an explicit red flag in your code by saying "no
strict" you are using symrefs anyhow but in one of the forms that is
exempted from use strict. So you get _all_ the disadvantages of using
symrefs plus two new disadvantages

1) It may not be so obvious that you are using symrefs.
2) All your subroutines now have an unwanted class argument.

> It's better to just use a dispatch table as the others said.

Not always. A perl symbol table (aka package) _is_ a dispatch table.
While there are good reasons why it's probably a bad idea to use the
same package as both a "normal" package and a dynamic dispatch at the
same time table there's no rational reason[1] not to have a Perl
symbol table that you use only for CODE that you want accessible via
dynamic dispatch.

[1] There are lot's of reasons - but I've never heard anyone defend
them without resorting to emotional/religious arguments.

Re: how to call sub by value in variable

On Aug 19, 1:56 am, "Petr Vileta" wrote:
> I have this simple script
>
> #!/usr/bin/perl
> use strict;
>
> foreach my $sub (qw/test1 test2/)
> {
> foreach my $name (qw/Petr John/)
> {
> no strict 'refs';
> &$sub($name);
> }
> }
>
> sub test1
> {
> my $txt=shift;
> print "Hallo $txt\n";
>
> }
>
> sub test2
> {
> my $txt=shift;
> print "Bye $txt\n";
>
> }
>
> I use no strict 'refs' and it work fine, but how to write this with strict
> refs? It is possible?

It's trivial to use CODE symrefs without switching off use strict.

(\&$sub)->($name);

But if you think that doing so would be an improvement then you've
misunderstood why we suggest using strict in the first place.

Re: how to call sub by value in variable

On Aug 19, 4:14 am, xhos...@gmail.com wrote:
> "Petr Vileta" wrote:
> > xhos...@gmail.com wrote:
> > > "Petr Vileta" wrote:
> > >> I have this simple script
>
> > >> #!/usr/bin/perl
> > >> use strict;
>
> > > my %dispatch = ( test1 => \&test1, test2 => \&test2);
>
> > >> foreach my $sub (qw/test1 test2/)
> > >> {
> > >> foreach my $name (qw/Petr John/)
> > >> {
>
> > > $dispatch{$sub}->($name);
>
> > Hmm, very nice ;-) By your solution I must define $dispatch{...} for all
> > my subs.
>
> Just for all of the ones you want to be runnable based on data from the
> database!

Which might be more than 3.

By my rule "if you are doing it 3 times you're (probably) doing it
wrong" manually doing ...

%dispatch = ( foo => \&foo, bar => \&bar, baz => \&baz);

.... would be wrong. Contrary to what some people may preach, there
_are_ things worse than using symrefs and maintaining a dispatch table
like the above with 50 entries in it is definitely one of them.

> > Of course it is correct practice but I get sub's names from
> > database. If I get sub name which not exist
>
> What do you use to know that it does not exist? What if it does exist,
> it just isn't a sub you want to be run based on data retrieved from
> the database?

> It seems to me to be very dangerous to run subroutines whose names are
> based on things generated beyond your control.

For this reason I suggest you prefix the names of the functions that
you want callable in this way with fixed string, indeed I'd usually
use a package name but it need not be a package name. That way no
matter what's in the input it won't be able to call any function other
than those you intended. It can only call a function you intended or
fail - so long as you don't define any functions with said prefix that
you don't intend to be called this way.

if (defined(&{"My::Handlers::$sub"})) {
no strict 'refs';
"My::Handlers::$sub"->($name);
} else {
warn "$sub not implemented\n";
}

You can check if the handler is defined as above but very often the
default behaviour of simply throwing an undefined subroutine exception
is actually the right thing to do anyhow.

> In other words, since what you want to do fundamentally violates the spirit
> of "use strict", the most straightforward way to do it is to turn off
> strict for that block.

Indeed

Re: how to call sub by value in variable

Brian McCauley wrote:
> It's trivial to use CODE symrefs without switching off use strict.
>
> (\&$sub)->($name);
>
Yippee :-) This is what I looked for.

> But if you think that doing so would be an improvement then you've
> misunderstood why we suggest using strict in the first place.
Of course, I rewrote my script (see other my mess here).

--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: how to call sub by value in variable - SOLVED

Petr Vileta wrote:
> My final solution.
Hmm, not final... maybe this will be final :-) Thanks for all for ideas to
helped me to write secure solution.

--- CUT ---
#!/usr/bin/perl
use strict;
use warnings;

foreach my $sub (qw/test1 test3 test2/)
{
foreach my $name (qw/Petr John/)
{
if(defined(&{"main::" . $sub}))
{
(\&$sub)->($name);
}
else
{
warn "Sub '$sub' not defined\n";
last;
}
}
}

sub test1
{
my $txt=shift;
print "Hallo $txt\n";
}

sub test2
{
my $txt=shift;
print "Bye $txt\n";
}
--- CUT ---

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Symrefs (was: how to call sub by value in variable)

Brian McCauley wrote:
> On Aug 19, 4:14 am, xhos...@gmail.com wrote:
>> "Petr Vileta" wrote:
>>> Hmm, very nice ;-) By your solution I must define $dispatch{...} for all
>>> my subs.
>>
>> Just for all of the ones you want to be runnable based on data from the
>> database!
>
> Which might be more than 3.
>
> By my rule "if you are doing it 3 times you're (probably) doing it
> wrong" manually doing ...
>
> %dispatch = ( foo => \&foo, bar => \&bar, baz => \&baz);
>
> ... would be wrong.

Considering the numerous postings in this group that warn for using
symrefs, I'm surprised to see that and other comments in this thread. Is

perldoc -q "variable name"

totally out of date?

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Re: Symrefs

>>>>> "GH" == Gunnar Hjalmarsson writes:

GH> Considering the numerous postings in this group that warn for using
GH> symrefs, I'm surprised to see that and other comments in this thread. Is

GH> perldoc -q "variable name"

GH> totally out of date?

i don't agree with using symrefs (in any form) for a dispatch table. i
haven't heard a decent argument from the OP why it can't be done in
advance as he knows the names of the subs in the DB. if he is worried
about hand editing a dispatch table with entries of 'foo' => \&foo then
that can be trivially automated. one easy answer is to put all the subs
into a separate module (namespace isn't important) and run a simple
filter to extract all the sub names into a dispatch table (modify that
module or write a fresh one). similarly a simple dbi query can dump the
names and be used to generate the dispatch table. this is no different
than using modules to generate accessors. in fact you could even do this
in some way with AUTOLOAD but that is clunky.

checking the symbol table (even with prefix names) is no different than
using a dispatch table (as someone has said) but it also means other
code can inject legal subs into the symbol table which are not
anticipated. only by controlling the dispatch table as a lexical do you
have the full safety you want.

my rule still stand, only mung the (or even lookup) in the symbol table
when you need to do it. otherwise use any other normal technique (other
than eval which is worse!). the symbol table is just a big hash tree
which is slower and not as safe as a lexical hash.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: how to call sub by value in variable - SOLVED

Petr Vileta wrote:
> Petr Vileta wrote:
>> My final solution.
> Hmm, not final... maybe this will be final :-) Thanks for all for ideas
> to helped me to write secure solution.
>
> --- CUT ---
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> foreach my $sub (qw/test1 test3 test2/)
> {
> foreach my $name (qw/Petr John/)
> {
> if(defined(&{"main::" . $sub}))
> {
> (\&$sub)->($name);
> }

Too obfuscated to my taste. If you don't want to use a dispatch table,
why not just:

no strict 'refs';
if ( defined &$sub ) {
$sub->($name);
}

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Re: Symrefs (was: how to call sub by value in variable)

On Mon, 20 Aug 2007 05:21:03 +0200, Gunnar Hjalmarsson
wrote:

>Considering the numerous postings in this group that warn for using
>symrefs, I'm surprised to see that and other comments in this thread. Is
>
> perldoc -q "variable name"
>
>totally out of date?

The general rule is: don't use symrefs if you don't know what you're
doing. But if you know what you're doing and you're doing it properly,
then what's the problem. Trying to circumvent that with clumsy
workaround doesn't seem that smart after all.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: Symrefs

Michele Dondi wrote:
> On Mon, 20 Aug 2007 05:21:03 +0200, Gunnar Hjalmarsson
> wrote:
>> Considering the numerous postings in this group that warn for using
>> symrefs, I'm surprised to see that and other comments in this thread. Is
>>
>> perldoc -q "variable name"
>>
>> totally out of date?
>
> The general rule is: don't use symrefs if you don't know what you're
> doing. But if you know what you're doing and you're doing it properly,
> then what's the problem.

I'm not sure; Was rather referring to the numerous opinionated posters
in this group who basically say: "Do not use symrefs - they are bad".

> Trying to circumvent that with clumsy
> workaround doesn't seem that smart after all.

That's very true in any case.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Re: Symrefs

On Mon, 20 Aug 2007 11:59:05 +0200, Gunnar Hjalmarsson
wrote:

>> The general rule is: don't use symrefs if you don't know what you're
>> doing. But if you know what you're doing and you're doing it properly,
>> then what's the problem.
>
>I'm not sure; Was rather referring to the numerous opinionated posters
>in this group who basically say: "Do not use symrefs - they are bad".

Yes of course: if you see the OP has no clue then you just tell her
not to use symrefs, they're bad. It's a first order approximation. The
next few terms are null, and then at some point you have a non-null
one: that's precisely where they *are* useful.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: Symrefs

Michele Dondi wrote:
> On Mon, 20 Aug 2007 11:59:05 +0200, Gunnar Hjalmarsson
> wrote:
>
>>> The general rule is: don't use symrefs if you don't know what you're
>>> doing. But if you know what you're doing and you're doing it properly,
>>> then what's the problem.

No, I did not write that. Please include proper attributions when quoting.

>> I'm not sure; Was rather referring to the numerous opinionated posters
>> in this group who basically say: "Do not use symrefs - they are bad".
>
> Yes of course: if you see the OP has no clue then you just tell her
> not to use symrefs, they're bad. It's a first order approximation. The
> next few terms are null, and then at some point you have a non-null
> one: that's precisely where they *are* useful.

You can never tell for sure that an OP "has no clue", and in any case
it's rude to disdain him/her that way. Besides, clpmisc is read by
hundreds of people, not just the OP.

If a question actually requires a less rigid answer, and you don't want
or have the time or whatever to provide that answer, you'd better keep
your mouth shut. ;-)

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Re: how to call sub by value in variable - SOLVED

Gunnar Hjalmarsson wrote:
> Petr Vileta wrote:
>> #!/usr/bin/perl
>> use strict;
>> use warnings;
>>
>> if(defined(&{"main::" . $sub}))
>> {
>> (\&$sub)->($name);
>> }
>
> Too obfuscated to my taste. If you don't want to use a dispatch table,
> why not just:
>
> no strict 'refs';
> if ( defined &$sub ) {
> $sub->($name);
> }
Yes, this may be used too, but I prefer to _not_ use no strict 'refs'. The
dispatch table is bad solution for me because now I have 10 subs in my
script but in future I will have about hundreds of subs and dispatch table
will be too huge. In other words - one man adding data to database and I'm
writing new subs when I get message from my error log ;-)
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)


--
Petr

Skype: callto://fidokomik

Na mail uvedeny v headeru zpravy nema cenu nic posilat, konci to v PR*
:-) Odpovidejte na petr na practisoft cz

Re: Symrefs

In article , Michele Dondi
wrote:

> On Mon, 20 Aug 2007 11:59:05 +0200, Gunnar Hjalmarsson
> wrote:
>
> >> The general rule is: don't use symrefs if you don't know what you're
> >> doing. But if you know what you're doing and you're doing it properly,
> >> then what's the problem.
> >
> >I'm not sure; Was rather referring to the numerous opinionated posters
> >in this group who basically say: "Do not use symrefs - they are bad".
>
> Yes of course: if you see the OP has no clue then you just tell her
> not to use symrefs, they're bad. It's a first order approximation.

My first approximation is "You can use symrefs yourself, but you can't
tell other people to use them".

This applies to everyone, not just to people who don't understand them.
:)

--
Posted via a free Usenet account from http://www.teranews.com

Re: how to call sub by value in variable - SOLVED

On 8/20/2007 8:59 AM, Petr Vileta wrote:
>
> I prefer to _not_ use no strict 'refs'.

As long as you know what you're doing, and why, it's fine.

> The dispatch table is bad solution for me because now I have 10 subs in my
> script but in future I will have about hundreds of subs and dispatch table
> will be too huge. In other words - one man adding data to database and I'm
> writing new subs when I get message from my error log ;-)

I'm not sure I follow this. If you have to write the subroutine anyway why is it
a problem to add one line to a dispatch table?

If you put all of the subs into a separate package you could generate the
dispatch table at runtime. (Although in this case symrefs would work just as well.)

-mjc

Re: how to call sub by value in variable - SOLVED

Petr Vileta wrote in comp.lang.perl.misc:
> Gunnar Hjalmarsson wrote:
> > Petr Vileta wrote:
> >> #!/usr/bin/perl
> >> use strict;
> >> use warnings;
> >>
> >> if(defined(&{"main::" . $sub}))
> >> {
> >> (\&$sub)->($name);
> >> }
> >
> > Too obfuscated to my taste. If you don't want to use a dispatch table,
> > why not just:
> >
> > no strict 'refs';
> > if ( defined &$sub ) {
> > $sub->($name);
> > }
> Yes, this may be used too, but I prefer to _not_ use no strict 'refs'. The

[...]

For completeness' sake, this also works under strict 'refs':

defined and $_->() for main->can( $sub);

Instead of "main" any package can be used, it could also be a variable
containing the package name. A problem is that "can()" does
inheritance, so if the package has a non-empty @ISA, a like-named sub
in another package could be found. The call itself is a plain sub
call, not a method call.

Anno

Re: Symrefs (was: how to call sub by value in variable)

On Aug 20, 4:21 am, Gunnar Hjalmarsson wrote:
> Brian McCauley wrote:
> > manually doing ...
>
> > %dispatch = ( foo => \&foo, bar => \&bar, baz => \&baz);
>
> > ... would be wrong.
>
> Considering the numerous postings in this group that warn for using
> symrefs, I'm surprised to see that and other comments in this thread. Is
>
> perldoc -q "variable name"
>
> totally out of date?

Definitely not. It doesn't talk about CODE symrefs.

Re: how to call sub by value in variable

On Aug 20, 3:09 am, "Petr Vileta" wrote:
> Brian McCauley wrote:
> > It's trivial to use CODE symrefs without switching off use strict.
>
> > (\&$sub)->($name);
>
> Yippee :-) This is what I looked for.

No! Please no! The above code is using symrefs but not _obviously_
using symrefs. If you are using symrefs your code should look like it
is. The easiest way to do this to put it in a a "no strict 'refs'"
block.

Re: Symrefs

On Aug 20, 4:42 am, Uri Guttman wrote:

> i don't agree with using symrefs (in any form) for a dispatch table. i
> haven't heard a decent argument from the OP why it can't be done in
> advance as he knows the names of the subs in the DB. if he is worried
> about hand editing a dispatch table with entries of 'foo' => \&foo then
> that can be trivially automated. one easy answer is to put all the subs
> into a separate module (namespace isn't important) and run a simple
> filter to extract all the sub names into a dispatch table (modify that
> module or write a fresh one).

There are things worse that symrefs. Code preprocessors are one of
them. And they are bad for exactly the same reason. Just like eval()
and symref() they blur the code/data divide.

> similarly a simple dbi query can dump the
> names and be used to generate the dispatch table. this is no different
> than using modules to generate accessors. in fact you could even do this
> in some way with AUTOLOAD but that is clunky.

I don't think the is talking about accessors that could be auto-
generated.

> checking the symbol table (even with prefix names) is no different than
> using a dispatch table (as someone has said)

That would be me.

> but it also means other
> code can inject legal subs into the symbol table which are not
> anticipated. only by controlling the dispatch table as a lexical do you
> have the full safety you want.

If code is maliciously putting stuff in packages that don't "belong"
to it then this is just as much of a problem whether or not that
package is being used as a dispatch table.

Re: Symrefs

Brian McCauley wrote:
> Just like eval()
> and symref() they blur the code/data divide.

That's exactly what made me feel uneasy from the very beginning.

Thou shalt not mix code and data

Therefore I would argue that the OPs idea of having the database control the
program execution is not a good idea in the first place and I would
investigate, if there is some better way to design the overall system.

However, if it really can't be helped, then at the very least very clearly
document why are violating this best practise and make it obvious in the
code, too. I would probably go with eval() in this case. It is bad, but it
is known to be bad and it is obvious that it is bad and therefore there must
be something very special going on, otherwise nobody would use it.

Trying to mask the bad code by casting it into on the surface inconspicous
code only confuses future maintainers of the code.

jue

Re: Symrefs

>>>>> "JE" == Jürgen Exner writes:

JE> Brian McCauley wrote:
>> Just like eval()
>> and symref() they blur the code/data divide.

JE> That's exactly what made me feel uneasy from the very beginning.

JE> Thou shalt not mix code and data

JE> Therefore I would argue that the OPs idea of having the database
JE> control the program execution is not a good idea in the first
JE> place and I would investigate, if there is some better way to
JE> design the overall system.

JE> However, if it really can't be helped, then at the very least very
JE> clearly document why are violating this best practise and make it
JE> obvious in the code, too. I would probably go with eval() in this
JE> case. It is bad, but it is known to be bad and it is obvious that
JE> it is bad and therefore there must be something very special going
JE> on, otherwise nobody would use it.

JE> Trying to mask the bad code by casting it into on the surface
JE> inconspicous code only confuses future maintainers of the code.

even though there may be duplication in the sub names and dispatch table
entry keys, i agree that having the DB hold those names is a bad idea. i
know reasons why you do that such as a personal list of plugins to load,
etc. but those names could be different than the actual sub names or
even map 1 to many (or many to 1) so a dispatch table (even manually
created) is safer as the coder controls what is allowed to be
called. using the symbol table to check for sub existance is bad because
of the possibility of calling code not under your control. as brian
said, that is nasty regardless of dispatch tables but it is just safer
IMO. i would consider the names in the DB as data that request
operations to be called rather than explicit sub names to be called by
symrefs.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: how to call sub by value in variable - SOLVED

On Aug 20, 3:29 am, "Petr Vileta" wrote:
> if(defined(&{"main::" . $sub}))
> {
> (\&$sub)->($name);
> }

That makes no sense. You should either have the package name or not.

if(defined(&$sub))
{
(\&$sub)->($name);
}

OR

if(defined(&{"main::$sub"}))
{
(\&{"main::$sub"})->($name);
}

If the current package is main then the two are equivalent anyhow.

But using %main:: as you dispatch table is a really really bad idea.
And remember I'm the one who's saying that using a package as a
dispatch table is not _always_ a bad idea. (It is, after all, how Perl
implements OO).

You should have _some_ way in your code of distinguishing those
subroutines that are are intended via dynamic dispatch and those which
aren't.

If you don't like my preferred approach of using a separate package
then consider a prefix (or suffix for that matter) so that they still
have a defined namespace. (That's namespace in the general sense).

#!/usr/bin/perl
use strict;
use warnings;

# Create dispatch table of all functions with _handler suffix
my %handler = map { /(.*)_handler$/ ? ( $1 => \&$_ ) : () } keys %::;

foreach my $action (qw/test1 test3 test2/) {
foreach my $name (qw/Petr John/) {
if( $handler{$action}) {
$handler{$action}->($name);
} else {
warn "Handler for '$action' not defined\n";
last;
}
}
}

sub test1_handler {
my $txt=shift;
print "Hallo $txt\n";
}

sub test2_handler {
my $txt=shift;
print "Bye $txt\n";
}
__END__

And before anyone else points it out, I do realise this would get
confused if you had, for example, a variable $main::test3_handler.

As Uri correctly points out you could replace the run-time examination
of %:: with a code preprocessor.

Re: how to call sub by value in variable - SOLVED

On Aug 21, 6:22 pm, Brian McCauley wrote:

> my %handler = map { /(.*)_handler$/ ? ( $1 => \&$_ ) : () } keys %::;

> And before anyone else points it out, I do realise this would get
> confused if you had, for example, a variable $main::test3_handler.

my %handler = map { ( /(.*)_handler$/ && defined &$_ ) ? ( $1 => \&
$_ ) : () } keys %::;

Re: Symrefs

On 8/21/2007 12:05 PM, Jürgen Exner wrote:
>
> Thou shalt not mix code and data

So no Lisp programming for you, eh? ;)

-mjc

Re: Symrefs

Michael Carman wrote:
> On 8/21/2007 12:05 PM, Jürgen Exner wrote:
>>
>> Thou shalt not mix code and data
>
> So no Lisp programming for you, eh? ;)

Lisp, lisp, lisp, wait a second, yes, you are right, there was such a
language a long time ago.
Wasn't that an acronym for _L_ots of _I_rritating _S_ingle _P_aranthesis?

The total lack of differentiation between code and data makes for some very
nice features like HOFs, closures, and others. But face it, LISP is almost
50 years old and many of its design features are shall we say not quite up
to date with modern principles of programming language design.

jue

Re: Symrefs

Uri Guttman wrote:
> even though there may be duplication in the sub names and dispatch
> table entry keys, i agree that having the DB hold those names is a
> bad idea. i know reasons why you do that such as a personal list of
> plugins to load, etc. but those names could be different than the
> actual sub names or even map 1 to many (or many to 1) so a dispatch
> table (even manually created) is safer as the coder controls what is
> allowed to be
> called. using the symbol table to check for sub existance is bad
> because of the possibility of calling code not under your control. as
> brian said, that is nasty regardless of dispatch tables but it is
> just safer IMO. i would consider the names in the DB as data that
> request operations to be called rather than explicit sub names to be
> called by symrefs.
>
Yes, you are right. But my reason to use sub names in DB is very simple. I
see I must to view the true :-)
I write web application for collecting weather data for as many locations as
possible. In internet are many servers with weather data. Some personal,
some business, some government. On some servers you can collect data about
tens or hundred towns, on some servers you can get data about one location
only. Of course, every server generate different html code which I must to
parse for get data.
A limited number of people in world have access to my database and can to
add new link to weather page. The "link" field in database have own unique
index and cannot be inserted twice. So as you can see for some pages the
links are similar, say
http://www.france-weather.fr?town=Paris
http://www.france-weather.fr?town=Caen
and I can use the same sub to parse html code. Other links are very
different and I must use very different subs. I don't know how many
locations/links I will have in DB next year or in 5 years ;-) And I don't
know too, how many subs I will have. Maybe links will be 5000 and subs 100,
maybe links will be 5000 and subs 4000.
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: how to call sub by value in variable

Brian McCauley wrote:
> On Aug 20, 3:09 am, "Petr Vileta" wrote:
>> Brian McCauley wrote:
>>> It's trivial to use CODE symrefs without switching off use strict.
>>
>>> (\&$sub)->($name);
>>
>> Yippee :-) This is what I looked for.
>
> No! Please no! The above code is using symrefs but not _obviously_
> using symrefs. If you are using symrefs your code should look like it
> is. The easiest way to do this to put it in a a "no strict 'refs'"
> block.

Why not? I like not obviously solutions :-) and this is smart and elegant.
Of course, no sctrict 'refs' is valid for some block, say while, foreach
etc., but if I use it then I must not forget to switch strict "on" if I add
some code in the same block in future. For me is better to not play with
strict on/off and use this syntax of sub calling.
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: Symrefs

Petr Vileta wrote:
> I write web application for collecting weather data for as many
> locations as possible. In internet are many servers with weather
> data. Some personal, some business, some government. On some servers
> you can collect data about tens or hundred towns, on some servers you
> can get data about one location only. Of course, every server
> generate different html code which I must to parse for get data.
> A limited number of people in world have access to my database and
> can to add new link to weather page. The "link" field in database
> have own unique index and cannot be inserted twice. So as you can see
> for some pages the links are similar, say
> http://www.france-weather.fr?town=Paris
> http://www.france-weather.fr?town=Caen
> and I can use the same sub to parse html code. Other links are very
> different and I must use very different subs. I don't know how many
> locations/links I will have in DB next year or in 5 years ;-) And I
> don't know too, how many subs I will have. Maybe links will be 5000
> and subs 100, maybe links will be 5000 and subs 4000.

You just described the perfect scenario for using a dispatch table.
Absolutely no need for messing around with eval() or symrefs or similar
workarounds.

jue

Re: Symrefs

>>>>> "PV" == Petr Vileta writes:

PV> A limited number of people in world have access to my database and can
PV> to add new link to weather page. The "link" field in database have own
PV> unique index and cannot be inserted twice. So as you can see for some
PV> pages the links are similar, say
PV> http://www.france-weather.fr?town=Paris
PV> http://www.france-weather.fr?town=Caen
PV> and I can use the same sub to parse html code. Other links are very
PV> different and I must use very different subs. I don't know how many
PV> locations/links I will have in DB next year or in 5 years ;-) And I
PV> don't know too, how many subs I will have. Maybe links will be 5000 and
PV> subs 100, maybe links will be 5000 and subs 4000.

that still is no excuse to use symrefs. when you write a new parser sub
you can add it to the dispatch table at the same time. it isn't extra
work. and a dispatch table will make it easier to map 100 subs to 5000
sites by the key names in the db. you can even make the key names
reflect the actual site name and the sub name reflect the style of
parsing. then the dispatch table is mapping many sites to fewer parse
subs. this way the db names are tied to the actual site which make it
easier to manage that.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: Symrefs

Jürgen Exner wrote:
> Petr Vileta wrote:
>> http://www.france-weather.fr?town=Paris
>> http://www.france-weather.fr?town=Caen
>> and I can use the same sub to parse html code. Other links are very
>> different and I must use very different subs. I don't know how many
>> locations/links I will have in DB next year or in 5 years ;-) And I
>> don't know too, how many subs I will have. Maybe links will be 5000
>> and subs 100, maybe links will be 5000 and subs 4000.
>
> You just described the perfect scenario for using a dispatch table.
> Absolutely no need for messing around with eval() or symrefs or
> similar workarounds.
>
Good haevens! :-) Dispatch table with 4000 entries? And manually update it?
No, thanks ;-)
When the sub name will be say 8 characters only + 2 characters => then it
means 40000 characters of needless code. For me is better to write 2 rows of
code to do script self-check.

# $parser contain sub's name
if(defined(&{"main::" . $parser})) { (\&$parser)->($parameter); }
else { warn "Sub $parser not exist\n"; }
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: how to call sub by value in variable

Petr Vileta wrote in comp.lang.perl.misc:
> Brian McCauley wrote:
> > On Aug 20, 3:09 am, "Petr Vileta" wrote:
> >> Brian McCauley wrote:
> >>> It's trivial to use CODE symrefs without switching off use strict.
> >>
> >>> (\&$sub)->($name);
> >>
> >> Yippee :-) This is what I looked for.
> >
> > No! Please no! The above code is using symrefs but not _obviously_
> > using symrefs. If you are using symrefs your code should look like it
> > is. The easiest way to do this to put it in a a "no strict 'refs'"
> > block.
>
> Why not? I like not obviously solutions :-) and this is smart and elegant.

"Smart" and "Elegant" are often the arch-enemies of maintainability.

> Of course, no sctrict 'refs' is valid for some block, say while, foreach
> etc., but if I use it then I must not forget to switch strict "on" if I add
> some code in the same block in future. For me is better to not play with
> strict on/off and use this syntax of sub calling.

If there isn't already a convenient block, use a bare block to isolate
"no strict ..."; A decent Perl coder will understand why it's there
and not add random code inside.

Anno

Re: Symrefs

Petr Vileta wrote:
> Jürgen Exner wrote:
>> Petr Vileta wrote:
>>> http://www.france-weather.fr?town=Paris
>>> http://www.france-weather.fr?town=Caen
>>> and I can use the same sub to parse html code. Other links are very
>>> different and I must use very different subs. I don't know how many
>>> locations/links I will have in DB next year or in 5 years ;-) And I
>>> don't know too, how many subs I will have. Maybe links will be 5000
>>> and subs 100, maybe links will be 5000 and subs 4000.
>>
>> You just described the perfect scenario for using a dispatch table.
>> Absolutely no need for messing around with eval() or symrefs or
>> similar workarounds.
>>
> Good haevens! :-) Dispatch table with 4000 entries? And manually
> update it? No, thanks ;-)

Don't you think that in particular in a case like this an additional
abstraction layer would be very convenient?
Then the person who enters the data in the DB can use a meaningful name
without the need to know how the subs are named in your program.

> When the sub name will be say 8 characters only + 2 characters => then it
> means 40000 characters of needless code.

How many characters to you expect your subs to be on average? Maybe 15 lines
of 30 characters each (just a guess, but I think in reality it will be
significantly larger)? Then we are talking about an increase in code size of
less than 3%.
To me a better architecture and cleaner code is well worth those additional
3%.

> For me is better to write 2 rows of code to do script self-check.

Suit yourself.

jue

Re: how to call sub by value in variable

"Petr Vileta" writes:
> Brian McCauley wrote:
> > On Aug 20, 3:09 am, "Petr Vileta" wrote:
> >> Brian McCauley wrote:
> >>> It's trivial to use CODE symrefs without switching off use strict.
> >>
> >>> (\&$sub)->($name);
> >>
> >> Yippee :-) This is what I looked for.
> >
> > No! Please no! The above code is using symrefs but not _obviously_
> > using symrefs. If you are using symrefs your code should look like it
> > is. The easiest way to do this to put it in a a "no strict 'refs'"
> > block.
>
> Why not? I like not obviously solutions :-) and this is smart and
> elegant.

Except for the minor fact that it's stupid and ugly...

> Of course, no sctrict 'refs' is valid for some block, say
> while, foreach etc., but if I use it then I must not forget to switch
> strict "on" if I add some code in the same block in future. For me is
> better to not play with strict on/off and use this syntax of sub
> calling.

This is getting remarkably cargo-cult ... you honestly mean that

sub do_iffy_dispatch {
my $function = shift;
no strict 'refs';
return $function->(@_);
}

is somehow LESS maintainable than jumping through dereference hoops?

To repeat what was said up thread: Once you have elected for good and
sufficient reason to use symrefs, walk up to the counter and in a loud
clear voice say, "Harry, I want you to sell me a condom..." no, wait,
that's a Monty Python sketch, instead you should say, "I have elected
for good and sufficient reason to use symrefs and I am going to flag
that call with a no strict refs to show that I know what I'm doing."

From the tortured metaphor department: If you are going to dig that
pit in the middle of the road, do not disguise it with spread out
newspapers, but but the well known flashing red light of a no strict
next to it, so that your replacement knows what is going on.

--
Lawrence Statton - lawrenabae@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
place them into the correct order.

Re: Symrefs

>>>>> "JE" == Jürgen Exner writes:

JE> The total lack of differentiation between code and data makes
JE> for some very nice features like HOFs, closures, and
JE> others. But face it, LISP is almost 50 years old and many of
JE> its design features are shall we say not quite up to date with
JE> modern principles of programming language design.

Huh?! Lisp has a history going back 50 years, but Lisp itself was
standardized in the mid-80s, roughly the same vintage as C. And most
of its design features were years ahead of their time....

I recommend that you take a serious look at Lisp before saying things
like this -- it's roughly analogous to saying "Perl? Oh, that's only
good for web scripting." It's a similar sort of misconception, and
just as wrong.

Charlton




--
Charlton Wilbur
cwilbur@chromatico.net

Re: Symrefs

Jürgen Exner wrote:
> Petr Vileta wrote:
>> Jürgen Exner wrote:
>>> Petr Vileta wrote:
>>>> http://www.france-weather.fr?town=Paris
>>>> http://www.france-weather.fr?town=Caen
>
> Don't you think that in particular in a case like this an additional
> abstraction layer would be very convenient?
> Then the person who enters the data in the DB can use a meaningful
> name without the need to know how the subs are named in your program.
>
Person store links to DB via web form (password protected) and the sub name
is auto-generated from URL.
Say, for example above, the generated sub name will be
"www_france__weather_fr" and of course this name is checked for existence
elsewhere in the DB.
Person can add many of the similar links to DB and if the sub exist then I
have no job ;-) If somebody add a new server (unknown in DB) then I get
email report about non-existing sub and I write it.

>> When the sub name will be say 8 characters only + 2 characters =>
>> then it means 40000 characters of needless code.
>
> How many characters to you expect your subs to be on average? Maybe
> 15 lines of 30 characters each (just a guess, but I think in reality
> it will be significantly larger)? Then we are talking about an
> increase in code size of less than 3%.
I prefer code with self-checking and self-learning functions. Yes, this case
is not "artificial intelligence" but allow to people work with minimal
efforts. I started my programming on control systems in assembler and this
practices was be usual. Self -checking, -learnign, -modifying programs.
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: Symrefs

Quoth "Petr Vileta" :
>
> Person store links to DB via web form (password protected) and the sub name
> is auto-generated from URL.
> Say, for example above, the generated sub name will be
> "www_france__weather_fr" and of course this name is checked for existence
> elsewhere in the DB.
> Person can add many of the similar links to DB and if the sub exist then I
> have no job ;-) If somebody add a new server (unknown in DB) then I get
> email report about non-existing sub and I write it.

I don't understand why your subs need to be in a symbol table at all.
Why can't you just store them directly in the dispatch table? Then you
don't need to worry about quoting the names.

my %dispatch = (

'www.france.weather.fr' => sub { ... },

...

);

sub do_dispatch {
my ($site, @args) = @_;

my $sub = $dispatch{$site};

if ($sub) {
return $sub->(@args);
}
else {
return send_email_and_fail($site, @args);
}
}

> I prefer code with self-checking and self-learning functions. Yes, this case
> is not "artificial intelligence" but allow to people work with minimal
> efforts. I started my programming on control systems in assembler and this
> practices was be usual. Self -checking, -learnign, -modifying programs.

Self-modifying code was perhaps common in the days of assembler, because
assembler is an incredibly primitive language and there was often no
other way to implement features in the tiny amount of space available on
early machines. The world has changed since then, and writing clean code
is not only desirable but easy with modern languages.

Ben

--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
ben@morrow.me.uk
--
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
'Alcestis') [ flame, and falls out of sight. ] ben@morrow.me.uk

Re: Symrefs

Ben Morrow wrote:
> Quoth "Petr Vileta" :
>>
> I don't understand why your subs need to be in a symbol table at all.
> Why can't you just store them directly in the dispatch table? Then you
> don't need to worry about quoting the names.
>
> my %dispatch = (
>
> 'www.france.weather.fr' => sub { ... },
>

Because:

my %dispatch = (
'www.france-weather.fr' =>sub {100 - 500 lines of code}
....
:-)

--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

Re: Symrefs

On Aug 23, 2:33 pm, Ben Morrow wrote:

> I don't understand why your subs need to be in a symbol table at all.
> Why can't you just store them directly in the dispatch table?

Anonymous functions are a pain in the backtrace.

Re: Symrefs

Quoth "Petr Vileta" :
> Ben Morrow wrote:
> > Quoth "Petr Vileta" :
> >>
> > I don't understand why your subs need to be in a symbol table at all.
> > Why can't you just store them directly in the dispatch table? Then you
> > don't need to worry about quoting the names.
> >
> > my %dispatch = (
> >
> > 'www.france.weather.fr' => sub { ... },
> >
>
> Because:
>
> my %dispatch = (
> 'www.france-weather.fr' =>sub {100 - 500 lines of code}
> ...
> :-)

How is this either more or less readable than

sub www_france_weather_fr {
# 100--500 lines of code
}

? Separate your subs out properly into bits (I'm sure a lot of them have
large sections in common), and define those bits as named subs. Then
buid the subs in the dispatch table from the bits.

Ben

--
Like all men in Babylon I have been a proconsul; like all, a slave ... During
one lunar year, I have been declared invisible; I shrieked and was not heard,
I stole my bread and was not decapitated.
~ ben@morrow.me.uk ~ Jorge Luis Borges, 'The Babylon Lottery'

Re: Symrefs

Quoth Brian McCauley :
> On Aug 23, 2:33 pm, Ben Morrow wrote:
>
> > I don't understand why your subs need to be in a symbol table at all.
> > Why can't you just store them directly in the dispatch table?
>
> Anonymous functions are a pain in the backtrace.

#!/usr/bin/perl

use strict;
use warnings;

use Carp qw/confess/;
use Sub::Name qw/subname/;

my %dispatch = (
'www.france-weather.fr' => sub { confess "error"; },
);

subname $_, $dispatch{$_} for keys %dispatch;

$dispatch{'www.france-weather.fr'}->();

__END__

~/src/perl% perl subname
error at subname line 10
main::www.france-weather.fr() called at subname line 15

Ben

--
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
'Alcestis') [ flame, and falls out of sight. ] ben@morrow.me.uk