On Mon Jan 02 01:05:39 2012, JKEGL wrote:
Show quoted text> @Father Chrysostomos:
>
> In the patch, should the test be if $] >= 5.015? That is
> greater-than-or-equal instead of greater-than?
Yes, you’re right. I wrote it sloppily based on the assumption that no one would be using a
development version.
Show quoted text>
> My idea is that you're telling me something like the following:
>
> 1.) A GLOB (call it a "pure-GLOB") and a scalar assigned a GLOB (call it
> a "scalar-GLOB") are distinct internally, but both test as GLOB's.
Yes. The main difference is that assigning over the former will do a special glob assignment
(e.g, *foo = \&bar assigns to a single slot), whereas assigning over the latter will clobber the
glob entirely, as in $foo = *foo; $foo = \&bar;.
This distinction is something left over from Perl 4 that is impossible to remove. (Personally I
think it was a bad design to begin with.)
Show quoted text> 2.) Before 5.15, I've no choice but to work only with the GLOB for both
> pure- and scalar-GLOBs.
Unless you use B.pm, but such solutions are usually fragile.
Another thing you could do is assume the tie is well-behaved and do local($var)=undef; to
see whether that causes tied($var) to return anything.
Show quoted text> 3.) 5.15 and after, the warning is gone and I can and should look at
> both the GLOB and the scalar.
Come to think of it, my patch is flawed. If the glob is something returned by a tied method,
you probably don’t want to visit it at all, do you?
To me it would make sense to do the scalar-tied check first and only do the handle-tied
check after that.
Looking at your handling of REF, I see that you don’t skip the usual code when there is a tie.
Is that code really correct? A tied variable could return a strong copy of an internal weak
reference, resulting in false positives.
Show quoted text>
> 4.) Your patch avoids the warning because "tied *$x" avoids it for both
> pure- and scalar-GLOBs in both versions. "tied $x" does not avoid the
> warning before 5.15, so you test for the perl version.
That’s right. Before 5.15, tied($x) and tied(*$x) would do the same thing in the case of
reftype(\$x) eq 'GLOB'.
Show quoted text>
> 5.) Your patch deals with pure-GLOBs because "if ($] > 5.015 and my
> $tied_var2 = tied ${$follow_probe})" will be false if "tied
> ${$follow_probe}" is undef, which it will be in the case of a pure-GLOB.
> (Or will it?)
Well, this is one of the things I don’t like about the typeglob model to begin with. On a pure-
GLOB, tied ($x) and tied (*$x) return exactly the same thing.
This means that the same tied object will be pushed on to @child_probes twice, but you have
a check for duplicates elsewhere.
Show quoted text> 6.) But can't tied ${$follow_probe} be a Perl false in the case of some
> scalar GLOB's?
Yes it can. I don’t understand your concern. If the scalar ${$follow_probe} is tied, it will
return true; otherwise false. If the handle *${$follow_probe} is tied, tied ${$follow_probe} will
return false (unless ${$follow_probe} is a tied scalar returning a tied handle), but tied
*${$follow_probe} will return true.
Show quoted text> Do all GLOB's test Perl true?
Do you mean !!tied $glob or !!$glob? The former, not necessarily; the latter, yes. I don’t
think I understand (the purpose of) your question.
Show quoted text> I wonder if the best way to deal with the scalar side of a scalar GLOB
> is to note in my documentation that it is discarded? I'd much rather
> take a change on a poorly featured release than a buggy one.
That would be reasonable.
Show quoted text> I am concerned about these things:
>
> As I am currently set up, I cannot really test that code targeted at
> 5.15 and later works. And it looks like this stuff is tricky enough
> that I really would want to test, and not just via cpantesters. Also,
> at present, my test suite coverage for GLOB's is very meager -- although
> I suspect that it adequately reflects the level of user interest.
>
> Another thing is, is any of this in the main Perl docs? I don't want to
> aggressively track undocumented behaviors which I can avoid it.
The edge cases are not all documented, but I could change that. I stated above that it would
be reasonable not to support scalar ties on globs, simply because this is one area of perl that
is so buggy that you’ll find different behaviours in different versions.
In 5.12 and earlier, this sets $foo to \&bar, believe it or not:
my $foo = *thing;
*$foo = \&bar; # clobbers the glob, despite the *
As of 5.14, *$foo actually returns a copy of the glob, with flagged internally as a pure-GLOB,
so that assignments like that will work.
Show quoted text> And I really wonder if in this case the payoff for being aggressive
> about catching this corner case is there. By default, GLOB's are not
> tracked by Test::Weaken at all.
Well, this is what it comes down to in the end. Globs and tied variables are buggy enough
that the cases where these things matter are probably rare, if at all existent.
Show quoted text> Their lifetime is rarely expected to be
> the same as that of the object which contains them, so most users prefer
> to ignore them entirely.
>
> With a note in the Test::Weaken docs, users will be alerted, and I'll be
> able to revisit this issue once things settle. Maybe by then I'll have
> new hardware and can perlbrew 5.15.
>
> @Father Chrysostomos: Thanks for your guidance in this matter, which
> have clarified this matter a great deal.
With this message, I fear I may have done the opposite. :-)
Show quoted text>
> On Sun Jan 01 23:52:30 2012, SPROUT wrote:
> > On Sun Jan 01 22:55:46 2012, JKEGL wrote:
> > > If you look at the larger context, you'll see the cases are mutually
> > > exclusive, with the first to apply ending the FIND_CHILDREN block via a
> > > last statement. I added a case dedicated to 'GLOB'. Leaving the test
> > > for $object_type eq 'GLOB' in a case tested for later, such the one
> > > quoted below, would be useless and highly misleading.
> >
> > OK, then how about the attached patch?
>
>
