develooper Front page | perl.perl5.porters | Postings from October 2011

[perl #102464] is warning valid?

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
October 29, 2011 07:00
Subject:
[perl #102464] is warning valid?
Message ID:
rt-3.6.HEAD-31297-1319896835-1216.102464-15-0@perl.org
On Sat Oct 29 05:56:22 2011, Hugmeir wrote:
> On Sat, Oct 29, 2011 at 8:59 AM, Linda Walsh <perlbug-
> followup@perl.org>wrote:
> 
> > # New Ticket Created by  Linda Walsh
> > # Please include the string:  [perl #102464]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=102464 >
> >
> >
> >
> > This is a bug report for perl from perl-diddler@tlinx.org,
> > generated with the help of perlbug 1.39 running under perl 5.12.3.
> >
> >
> > -----------------------------------------------------------------
> > [Please describe your issue here]
> >
> > To be honest, I'm not even sure this is a real bug, or is be
> > design, but it seems counterintuive.
> >
> > if I test a variable for being 'defined' :
> >
> >        if (defined($foo)) {
> >                print "foo=$foo\n";
> >        }
> >
> >
> >        Should I, even under strict (which is the case), get:
> >
> > Global symbol "$foo" requires explicit package name at -e line 3.
> > Execution of -e aborted due to compilation errors.
> >
> >
> > I can understand *why* it happens, but *should* it happen?
> > I.e. in the above example, that "$foo" isn't defined is not a
> > 'design error' and it not being defined is checked for, preventing
> > it's use.  So should it cause a "parse-time" error?
> >
> > Not a common case or that important, but it just seemed 'off'...
> >
> >
> > But it also might be the case that's more work than it is
> > worth to correct it...?
> >
> > C'est la vie!... ;-)
> >
> >
> > an error
> > and is checked for"$foo" has no need to be defined --
> >
> > Should it be an error if the variable is I mean should I get the
> error if
> > it is in
> >
> >
> The general use case for defined[*] is whenever something stored
> inside a
> variable is not undef, not whenever the variable itself exists. Doing
> the
> latter would encourage people to use, say, symbolic references instead
> of
> hashes, so it seems like a bad idea.
> 
> Certainly there's stuff like defined &func which throw the above out
> of the
> window, but that's an exception to the rule.

It’s only special-cased, like defined $_[0], not to create the thingy if
it doesn’t exist.  defined &func tells you whether &func has a body.

defined &$code_ref can sometimes return false.

> If you want to know
> whenever a
> global is defined or not, you could do something like
> defined ${ \our $foo }
> (However, that adds foo to the current package's symbol table,

You’re not supposed to worry about that, unless you’re a core hacker.

> so
> perhaps
> something like
> exists $::{__PACKAGE__} && exists ${ __PACKAGE__ . "::" }{foo}
> && *{__PACKAGE__ . "::foo"}{VARTYPE} && defined ${*{__PACKAGE__ .
> "::foo"}{VARTYPE}}
> ...which needs even more massaging if __PACKAGE__ has multiple parts,
> but
> you get the idea.)
> 
> There's unfortunately no built-in to check if a lexical variable
> exists in
> the current scope, though it's possible to roll your own if you don't
> mind
> using a bit of XS (see pad_findmy in perlapi and/or the CvPADLIST
> macro, or
> PadWalker in CPAN for a more backwards-compatible solution). But the
> real
> question here is, why would you want to do that? Are you trying to sue
> a
> variable as a variable name? If so, please read
> http://perl.plover.com/varvarname.html and consider using a hash
> instead.
> 
> [*] defined @array and defined %hash being deprecated for a reason.


-- 

Father Chrysostomos


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About