Front page | perl.perl5.porters |
Postings from March 2008
Re: Oldie but goodie: glob in scalar context
Thread Previous
|
Thread Next
From:
Peter Scott
Date:
March 27, 2008 16:48
Subject:
Re: Oldie but goodie: glob in scalar context
Message ID:
6.2.3.4.2.20080327142410.0237cd20@mail.webquarry.com
At 12:37 PM 3/27/2008, Yitzchak Scott-Thoennes wrote:
>On Thu, March 27, 2008 11:28 am, Peter Scott wrote:
> > I just found the discussion at
> > http://groups.google.com/group/perl.perl5.porters/browse_thread/thread/540
> > 1ccdcbd6d4fa1/
> > the hard way. It appears to have petered out and I would like to reopen
> > it.
>[...]
> > Imagine that user is then trying to use the debugger that you have taught
> > them to use, on an expanded version of this so they can inspect $_
> > before the glob call, and they find that when they type
> >
> > DBG> x glob "/home/?/$_"
> >
> > it produces a different result from what the program itself does when
> > they take the next step. It's somewhat embarrassing and not a little
> > convoluted to explain to them that this is their fault.
>
>Carried to extremes, that argument would banish all context-dependent
>behavior.
Well, if I carry it to extremes I hope you will object :-)
> > I think that scalar glob iteration should be reset when the value of its
> > expression changes. This is what Schwern and chromatic espoused in the
> > thread I cite above.
>
>I'm afraid to look in that thread lest I disagree with myself,
Carried to extremes, that argument would banish all self-written
material reading :-)
> but at
>this time, I feel like this would be sweeping the problem under the
>carpet. In point of fact, reusable code which uses scalar-context glob
>without making sure to exhaust the iterator is buggy. Suppose you have
>this code instead:
>
>sub direxists {
> print "checking for $_[0]\n";
> print "$_[0] not found\n" unless glob "/home/?/$_[0]"
>}
>
>Your proposed fix would make it work except in the case of being
>called with the same parameter twice in a row (where the directory
>does exist), an even harder problem to debug.
Granted, but I think it is at least easier to defend. The current
behavior is due to the context argument that is supplied by perl and
unique per lexical instance. Try explaining to someone why this:
print glob("/foo/?") ? "Yes" : "No";
print glob("/foo/?") ? "Yes" : "No";
produces a different result from this:
for (1..2) {
print glob("/foo/?") ? "Yes" : "No";
}
>I'd rather see a warning for scalar-context glob not in a while()
>condition, or something like that. (And even that is buggy if the
>while loop may be prematurely terminated with last or an exception.)
How about this. An analogous situation is scalar m//g, which could get
you into trouble if you tried hard enough:
my $x = "cba";
for (qw(a b c))
{
print "$x matched /$_/\n" if $x =~ /$_/g;
}
cba matched /a/
cba matched /c/
But in that case, clearly what the author would be more likely to do
instead would be to leave the g modifier off. But glob() is overloaded
too much; there's no way of telling it to reset the iterator. Even
testing for boolean context isn't good enough because someone might
decide to count files with C<$count++ while glob $expr>.
There is, however, room for a second argument - currently a syntax
error. So how about
glob EXPR, FLAGS
where glob $pattern, ":RESET" would force glob to flush its queue for
that context first?
Thread Previous
|
Thread Next