[Phoenix-pm] Running a SQL program within PERL DBI

[Metz, Bobby W, WCS]

	Well, I was looking for a simple "yes, P5 call without & works",
but I like the example.  That said, I'm sure I'm opening myself up for
ridicule, but the way I learned subs was that you pass the reference to
the hash, not the var itself.

	sub foo (\%) { print "Scott foo: ", $_[0]->{foo}, "\n";
$_[0]->{foo} .= " Scott"; }
	my %stuff = (foo => "bar");
	foo(%stuff);
	&foo(%stuff);

	sub foo2 { print "Bob foo: ", $_[0]->{foo}, "\n"; $_[0]->{foo}
.= " Bob"; }
	my %stuff = (foo => "bar");
	foo2(\%stuff);
	&foo2(\%stuff);

	Output:
	Scott foo: bar
	Scott foo: 
	Bob foo: bar
	Bob foo: bar Bob

	Guess this has always made more sense to me since I first cut my
teeth on ANSI C where you had to pass the ref to modify the values.  So,
by passing the ref I can read and write.  But, it doesn't make an
argument for using & since either calling method with the hash ref
works, so I see the "yes" answer I was looking for and I don' t have to
change my style (again, ridicule?).

Bobby

-----Original Message-----
From: Scott Walters [mailto:scott at illogics.org]
Sent: Thursday, March 16, 2006 8:58 AM
To: Anthony R. Nemmer
Cc: Metz, Bobby W, WCS; phoenix-pm at pm.org; Loo, Peter # PHX
Subject: Re: [Phoenix-pm] Running a SQL program within PERL DBI


Hi Tony,

In Perl 6, &sub is a reference to the sub, like \&sub in Perl 5.  Or
something like that.  Typeglobs are going away, of course.  

Even if you don't use prototypes, other people might, and then & breaks
the code.

sub foo (\%) { print "stuff: ", $_[0]->{foo}, "\n"; }

my %stuff = (foo => "bar");

foo(%stuff);
&foo(%stuff);

When calling functions exported by modules (or not exported), you don't
know
if they're using prototypes.  Yes, prototypes are a bit of a hack, but
only
insomuch as they aren't complete.  I'd love to be able to prototype
things
like how grep $_ eq 5, @numbers or map "$_\n", @things work, where the
first
argument is an expression that gets treated like a code block.

&foo also defaults to sending @_ in the function call, which is
sometimes handy
but in other classes makes action-at-a-distance too easy, clobbering @_
in
some remote subroutine.

But most of all, &foo identifies the programmer as someone who learned
to 
program by immitating someone who immitated someone else and now writes
Perl like Matt Wright.

As for whether or not Perl 4 is inherently bad, no, of course not.  Perl
1
isn't inherently bad.  But Perl 5 offers some major improvements --
three
argument open, two argument system (for security), references (no more
nasty
glob tricks to pass datastructures), etc.  If you want to write in a
Perl 4
style and actually *know* Perl 4 and aren't just doing a Matt Wright
impression,
that's fine, but IMO (I AM GOD EVERYTHING I SAY IS RIGHT EVERYONE WHO
DISAGREES
IS WRONG) even old Perl 4 programmers should come up to speed on those
few
things or else they're writing inferior code by any metric.

Okay, rant done =)

-scott

On  0, "Anthony R. Nemmer" <intertwingled at qwest.net> wrote:
> What SPECIFICALLY is wrong with using the & to identify a subroutine 
> call, if I am not using prototypes?  Are you saying that it just makes

> the code look uglier?  I always thought prototypes were a hack anyway.
> 
> Perl has always used sigils to identify various entities...
> $ for scalars, @ for arrays, % for hashs, \ for references, * for 
> typeglobs, & for subroutines.  If I am not using prototypes, I don't
see 
> what the problem is with using & to identify a subroutine call.
> 
> I understand that this may all change in Perl 6.
> 
> Tony
> 
> Metz, Bobby W, WCS wrote:
> > Hey thanks for the "&" tip.  Old habit I guess since the folks I
learned
> > from used it in all their code and I've never read up on Perl 5
calls to
> > find out otherwise.  Thought I knew what I was doing :-)
> > 
> > So, just "@results = mysql_mod::execute($my_sql_file);" does the
trick?
> > 
> > Bobby
> > 
> > -----Original Message-----
> > From: Scott Walters [mailto:scott at illogics.org]
> > Sent: Wednesday, March 15, 2006 7:07 PM
> > To: Metz, Bobby W, WCS
> > Cc: Loo, Peter # PHX; phoenix-pm at pm.org
> > Subject: Re: [Phoenix-pm] Running a SQL program within PERL DBI
> > 
> > 
> >> use mysql_mod;
> >> $my_sql_file = "blahblahblah"
> >> @results = &mysql_mod::execute($my_sql_file);
> > 
> > Bobby, Peter,
> > 
> > I'd like to encourage you to drop the &, though.  You needed it in
Perl
> > 4;
> > in Perl 5, you don't, but gives you a funky Perl 4 compatability
mode
> > where prototypes are disabled.  You don't want this.  It breaks
things.
> > 
> >> foreach $line (@results)
> >>  {
> >>   # pattern match whatever
> >>   # call other routines
> >>   # etc.
> >>  }
> >>
> >> This could save you time cut/pasting or re-writing the sqlplus
call,
> > 
> > Yes, there's absolutely no reason why you can't put SQL in a file
> > rather than hard-code it into a program.  
> > 
> >> redirection, or whatever, each and every time you have a new script
> >> need.  Again, no point trying to parse the .sql file to perform the
> >> queries in DBI...just process the output from sqlplus.
> > 
> > ... and I posted something that would fork off a process and run it
> > in the SQL shell.
> > 
> >> 	As to leaving the group...give us another chance.  I agree with
> >> Brock that your original problem statement wasn't well defined and
I
> > 
> > If it makes you feel any better, I make about $5/hour >=)
> > 
> > -scott
> > _______________________________________________
> > Phoenix-pm mailing list
> > Phoenix-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/phoenix-pm
> > 
> > 
> 
> 
> -- 
> 
> I always have coffee when I watch radar!
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm