Re: Things that suprised me about perl syntax
* Randal L. Schwartz ([EMAIL PROTECTED]) wrote: > > "Leon" == Leon Brocard <[EMAIL PROTECTED]> writes: > > Leon> From now on, I shall be using the two terms interchangably > Leon> just to prove my point. > > Hey hey. No need to get hostile. > Could you two please take this off the mailing array ;-) -- Greg McCarroll http://www.mccarroll.org.uk/~gem/ jabber:[EMAIL PROTECTED] msn:[EMAIL PROTECTED]
Re: Things that suprised me about perl syntax
Randal L. Schwartz sent the following bits through the ether: > Hey hey. No need to get hostile. Sorry. It took me all week to get hostile. I normally never have an opinion on any subject, but I'd been saving up some opinions for today. Tomorrow I shall have no opinions. Hey, if you're lucky, I'll have no opinions next week either. Apart from orange, of course. Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... The gene pool could use a little chlorine
Re: Things that suprised me about perl syntax
> "Leon" == Leon Brocard <[EMAIL PROTECTED]> writes: Leon> From now on, I shall be using the two terms interchangably Leon> just to prove my point. Hey hey. No need to get hostile. -- 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!
Re: Things that suprised me about perl syntax
> "Mark" == Mark Fowler <[EMAIL PROTECTED]> writes: Mark> On 29 May 2002, Randal L. Schwartz wrote: >> Mark Fowler wrote: >> > array context >> What the heck is "array context"? Mark> It's like list context but with all the wrong letters in the first word Mark> due to sudden brain failure of the author. On re-reading, my tone could be misunderstood... what I was trying to get at was to see if you *were* distinguishing this from "list context" having some other odd properties... like mistakenly thinking that something in "array context" would return its length if assigned to a scalar or something. I've seen whacko stuff like that in print before. People get the weirdest ideas about context, when it's so completely predictable and straightforward. I'm not sure how the memes get so hosed up. -- 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!
Re: Things that suprised me about perl syntax
Mark Fowler wrote: > Or you could just use Test::Differences ;-) > > http://search.cpan.org/search?dist=Test-Differences Ah. Looks interesting. Thanks! (One small disadvantage, after looking at the docs, is that my check() function can print out "blurfle", "waffle", and "bagel" as tags for the three output items while Test::Differences can only number then 0 1 2 or 1 2 3... but my real code doesn't have *that* many output items anyway (maximum of 10 IIRC).) Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> All opinions are my own, not my employer's. If you're not part of the solution, you're part of the precipitate.
Re: Things that suprised me about perl syntax
On Thu, May 30, 2002 at 12:00:19PM +0200, Newton, Philip wrote: > Paul Makepeace wrote: > > On Thu, May 30, 2002 at 08:44:54AM +0200, Newton, Philip wrote: > > > Unfortunately, myfunction() "return;"s if it doesn't know > > > what to do with 'input' > > > > Why not just explicitly return undef? > > Oh, I dunno. I just kind of thought "return;" was cooler, I guess. I tend to regard any subroutine that does return undef; instead of plain return; with a degree of suspicion. I then look carefully at the rest of the subroutine to see whether it's explicit that it returns undef for this case, or whether it's just returning falsehood. If it's only returning falsehood then in my opinion it would be more useful (and therefore better) by being more general and returning nothing. That way it becomes useful in both scalar and list context. With return undef; it pollutes in list context. (And yes, if I want undef into a list, I can write C before it, which is simple. The code to detect a list of 1 item that is exactly undef and replace that with () is sufficiently non-trivial that I can type this sentence faster than writing it in this e-mail. And the falsehood return of (undef) could get confused with a legitimate 1 item list that happens to contain undef.) So I don't regard "return;" as cooler - I regard "return;" as more generic, and therefore better (in the general case) as I prefer more flexible interfaces. Nicholas Clark
Re: Things that suprised me about perl syntax
On Thu, 30 May 2002, Newton, Philip wrote:
> Hm, have to think about it some more.
Or you could just use Test::Differences ;-)
http://search.cpan.org/search?dist=Test-Differences
Later.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
Re: Things that suprised me about perl syntax
Paul Makepeace wrote:
> check('input', [myfunction('input')], [ qw/out1 out2 out3/ ]);
I did do that for 'otherfunction', since that does something different in
scalar and list context:
check('input', scalar(otherfunction('input')), [ blabla ]);
check('input') [ otherfunction('input') ], [ blabla ]);
> ..which makes the interface to check a little more internally
> consistent.
Have to think about that.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
All opinions are my own, not my employer's.
If you're not part of the solution, you're part of the precipitate.
Re: Things that suprised me about perl syntax
Paul Makepeace wrote: > On Thu, May 30, 2002 at 08:44:54AM +0200, Newton, Philip wrote: > > Unfortunately, myfunction() "return;"s if it doesn't know > > what to do with 'input' > > Why not just explicitly return undef? Oh, I dunno. I just kind of thought "return;" was cooler, I guess. > It call to a function is expecting a value, it's only polite > to present it with a value. I guess. (Either of 'undef' [in scalar context] and the empty list [in list context] is false, though.) > Or, always return a reference which could of course include [] -- > that wouldn't get squished away. That might be something to consider. But I think undef is nicer because you can test for truth more easily that way. Hm, have to think about it some more. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> All opinions are my own, not my employer's. If you're not part of the solution, you're part of the precipitate.
Re: Things that suprised me about perl syntax
On Thu, May 30, 2002 at 10:42:04AM +0100, Mark Fowler wrote:
> On Thu, 30 May 2002, Paul Makepeace wrote:
>
> > Why not just explicitly return undef? It call to a function is expecting
> > a value, it's only polite to present it with a value.
> >
> > Or, always return a reference which could of course include [] -- that
> > wouldn't get squished away.
>
> Remember that check was a testing function. A testing script shouldn't
> have to rely on functions that they're testing being properly written.
> Afterall, that's the point in testing them.
This is what I meant, (but didn't quite say),
check('input', [myfunction('input')], [ qw/out1 out2 out3/ ]);
..which makes the interface to check a little more internally consistent.
Paul
--
Paul Makepeace ... http://paulm.com/
"If I thought I could change the colour of the sky, then I'm a monkeys'
uncle."
-- http://paulm.com/toys/surrealism/
Re: Things that suprised me about perl syntax
On Thu, 30 May 2002, Paul Makepeace wrote:
> Why not just explicitly return undef? It call to a function is expecting
> a value, it's only polite to present it with a value.
>
> Or, always return a reference which could of course include [] -- that
> wouldn't get squished away.
Remember that check was a testing function. A testing script shouldn't
have to rely on functions that they're testing being properly written.
Afterall, that's the point in testing them.
Later.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
Re: Things that suprised me about perl syntax
On Wed, 29 May 2002 17:23:17 +0100 (BST), Mark Fowler wrote:
>my $foo = { delete => $cgi->param("delete") };
>
> May not do what you think, especially if someone went
>
>foo.cgi?delete=1;delete=filename;delete=/etc/shadow
Hey, don't spoil the only good bit of my TPC talk!
--
Peter Haworth [EMAIL PROTECTED]
'Are you *really* willing to deal with hundreds of newbies who don't
understand why $a . $b isn't the same as $a .$b and isn't the same as
$a. $b and isn't the same as $a.$b? And do you realise what the only
"good" answer we can possibly give them is? "Because Ed said so".'
-- Simon Cozens
Re: Things that suprised me about perl syntax
Mark Fowler sent the following bits through the ether: > It's like list context but with all the wrong letters in the first word > due to sudden brain failure of the author. List context is one of the things which always confused me. And the fact that the op is called wantarray hasn't helped either. Or the fact that "Perl Gurus" try and show off how much they know about the language by telling us all we know is wrong. This just results in more confusion. From now on, I shall be using the two terms interchangably just to prove my point. Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... Try? Try not. Do, or do not. There is no try
Re: Things that suprised me about perl syntax
On Thu, May 30, 2002 at 08:44:54AM +0200, Newton, Philip wrote:
> Unfortunately, myfunction() "return;"s if it doesn't know what to do with
> 'input'... with the result that the call is essentially
>
> check('input', [ qw/out1 out2 out3/ ]);
>
> which isn't really what I wanted. (I think I "solved" that one by putting an
> explicit scalar() around the call, though I could also have added a protoype
Why not just explicitly return undef? It call to a function is expecting
a value, it's only polite to present it with a value.
Or, always return a reference which could of course include [] -- that
wouldn't get squished away.
P
--
Paul Makepeace ... http://paulm.com/
"What is the answer to the question? An abominable pimple on the face of
God."
-- http://paulm.com/toys/surrealism/
Re: Things that suprised me about perl syntax
On 29 May 2002, Randal L. Schwartz wrote:
> Mark Fowler wrote:
> > array context
> What the heck is "array context"?
It's like list context but with all the wrong letters in the first word
due to sudden brain failure of the author.
Later.
Mark
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
Re: Things that suprised me about perl syntax
Mark Fowler wrote:
> What suprised you about Perl? What was a little quirk that
> you didn't expect? You might want to share with the list so
> we can all learn from one another's mistakes.
I was writing a module and writing lots of tests (pats self on the back).
While doing that, I fell afoul of the following combination:
* "return;" returns undef in scalar context and an empty
list in list context
* if you call a sub which has no prototype, it gives list
context to its arguments
* two adjacent commas in the middle of a list do not give
an empty argument; they just ignore it.
So what was happening was that I called something like
check('input', myfunction('input'), [ qw/out1 out2 out3/ ]);
to check whether myfunction('input') returns [ qw/out1 out2 out3/ ]. check()
was a function that calls Test::More's is() "n" times (n=3 in this example)
and checks whether the individual elements match what they should be. That
way, I don't have to write "n" is() calls for each input that I'm checking.
Unfortunately, myfunction() "return;"s if it doesn't know what to do with
'input'... with the result that the call is essentially
check('input', (), [ qw/out1 out2 out3/ ]);
(since myfunction() was called in list context due to the nonexistent
prototype of check()), which reduces to
check('input', [ qw/out1 out2 out3/ ]);
which isn't really what I wanted. (I think I "solved" that one by putting an
explicit scalar() around the call, though I could also have added a protoype
of ($$$) to check(), I suppose.)
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
All opinions are my own, not my employer's.
If you're not part of the solution, you're part of the precipitate.
Re: Things that suprised me about perl syntax
In message <[EMAIL PROTECTED]>, Jonathan Stowe <[EMAIL PROTECTED]> writes: > IEF868I 00E WTR WAITING FOR WORK P00 IHNJ, IJLTS "WAITING FOR WORK P00" -- rob partington % [EMAIL PROTECTED] % http://lynx.browser.org/
Re: Things that suprised me about perl syntax
On 29 May 2002, Clive Hills wrote: > On Wed, 2002-05-29 at 19:22, Jonathan Stowe wrote: ... > > IEF868I 00E WTR WAITING FOR WORK P00 > > Ooooh, that looks like MVS or MVT so I'd guess perhaps > that's Hercules/360? > Yep /J\
Re: Things that suprised me about perl syntax
On Wed, 2002-05-29 at 19:22, Jonathan Stowe wrote: > IEA100I TIMER IS NOT WORKING > IEA218I MOD=50 ASSUMED S360 > IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 21.0 MFT > HHC901I Enter input for console device 0009 > > IEA217I SEREP INTERFACE ESTABLISHED > *00 IEE801D CHANGE PARTITIONS- REPLY YES/NO (,LIST) > r 00,yes > IEE866I DEFINE COMMAND BEING PROCESSED > *00 IEE802A ENTER DEFINITION > r 00,p0=(a,512k),p1=(a,512k),end > IEE812I P 01 HAS 981480 EXCESS BYTES ADDED IN H0 > IEE805I DEFINITION COMPLETED > IEE101A READY > t date=(72.128),q=(,f) > IEE307I SET DELIMITER ERROR > t date=72.128,q=(,f) > *00 IEF423A SPECIFY JOB QUEUE PARAMETERS > r 00,u > mn jobnames,t > mn status > s wtr.p0,00e > IEF403I WTR STARTEDP00 > IEF236I ALLOC. FOR WTR P0 P00 > IEF237I 00E ALLOCATED TO IEFRDER P00 > IEF868I 00E WTR WAITING FOR WORK P00 Ooooh, that looks like MVS or MVT so I'd guess perhaps that's Hercules/360? Regards Clive -- Clive Hills | Solaris and Linux Systems | e: [EMAIL PROTECTED] Crayford| Administrator | Kent UK | UniVerse/Pick/Reality DBA |
Re: Things that suprised me about perl syntax
On Wed, 29 May 2002, Mark Fowler wrote: > Hey, look! A Perl Thread! > I'll soon fix that - this is much more fun: IEA100I TIMER IS NOT WORKING IEA218I MOD=50 ASSUMED S360 IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 21.0 MFT HHC901I Enter input for console device 0009 IEA217I SEREP INTERFACE ESTABLISHED *00 IEE801D CHANGE PARTITIONS- REPLY YES/NO (,LIST) r 00,yes IEE866I DEFINE COMMAND BEING PROCESSED *00 IEE802A ENTER DEFINITION r 00,p0=(a,512k),p1=(a,512k),end IEE812I P 01 HAS 981480 EXCESS BYTES ADDED IN H0 IEE805I DEFINITION COMPLETED IEE101A READY t date=(72.128),q=(,f) IEE307I SET DELIMITER ERROR t date=72.128,q=(,f) *00 IEF423A SPECIFY JOB QUEUE PARAMETERS r 00,u mn jobnames,t mn status s wtr.p0,00e IEF403I WTR STARTEDP00 IEF236I ALLOC. FOR WTR P0 P00 IEF237I 00E ALLOCATED TO IEFRDER P00 IEF868I 00E WTR WAITING FOR WORK P00 /J\
Re: Things that suprised me about perl syntax
> "Mark" == Mark Fowler <[EMAIL PROTECTED]> writes:
Mark> As we were discussing on IRC, "=>" (the 'fat comma') doesn't imply array
Mark> context
What the heck is "array context"? No such beast. And if you mean
"list context", then arrow has no more context forcing than a comma.
Both of them inherit context depending on their use.
For example,
$n = (15 => 30);
puts 30 in $n, as the second item evaluated. Replacing arrow with
comma will make that clear.
Mark> to it's right hand side argument, and CGI's param method does odd
Mark> things in list context (it returns *all* parameters of that name.) So:
Mark>my $foo = { delete => $cgi->param("delete") };
And yes, this is broken.
--
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!
Re: Things that suprised me about perl syntax
On Wed, May 29, 2002 at 05:23:17PM +0100, Mark Fowler wrote:
>Erk! Now your turn.
This is why many of my scripts have
my %param=map{$_ => [$q->param($_)]} $q->param;
near the top. Then I test for the existence of at least one copy of a
param with
exists $param{foo}
get the value of something that should only be there once with
$param{foo}->[0]
and get the value of something that occurs multiple times with
@{$param{foo}}
Makes life much easier. (Doesn't work with the magic file upload thingy,
of course.)
Roger
Things that suprised me about perl syntax
Hey, look! A Perl Thread!
What suprised you about Perl? What was a little quirk that you didn't
expect? You might want to share with the list so we can all learn from
one another's mistakes.
Up first, something lifted off of irc.
As we were discussing on IRC, "=>" (the 'fat comma') doesn't imply array
context to it's right hand side argument, and CGI's param method does odd
things in list context (it returns *all* parameters of that name.) So:
my $foo = { delete => $cgi->param("delete") };
May not do what you think, especially if someone went
foo.cgi?delete=1;delete=filename;delete=/etc/shadow
Now $foo contains;
{
delete => 1,
what => "/etc/shadow/"
}
Erk! Now your turn.
Later.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
