in reply to runtime eval() and constants

I kinda expected it to complain about a bareword,
You didn't even give perl a -w option, so it's no wonder you don't get warnings. However, be glad Perl won't warn about barewords when the bareword looks like a package name, or otherwise you'd get lots of warnings when constructing objects or calling class methods.
go resolve the bareword as a constant,
Note that if you require a module, it won't get executed until run time, so constants won't be made or exported until run time. Hence, if you do: 
    eval "require DBI; DBI::SQL_VARCHAR";

[download]
perl will compile DBI::SQL_VARCHAR as being a string before DBI.pm is executed (which will export the DBI::SQL_VARCHAR "constant".

Note that this isn't anything special about "eval". It just has to do with the order in which things are compiled/run.

Abigail

Replies are listed 'Best First'.
Re: Re: runtime eval() and constants
by dpmott (Scribe) on Dec 08, 2003 at 18:31 UTC
    perl will compile DBI::SQL_VARCHAR as being a string before DBI.pm is executed (which will export the DBI::SQL_VARCHAR "constant".
    Ah, yes, that's what I thought was happening.

    Just for reference -- I intentionally used 'require' because eval() will capture the die() generated from a require statement, if it can't find the module. If you eval{ use Blah }, then you don't get the opportunity to capture that die().

    I also discovered that I could have two separate evals, one for the require, and then one for the constant. However, it seemed more efficient to me to put them both into one eval(). It works too, so long as I keep the compliation order in mind...

    Thanks for all of the good feedback :)

    -Dave
[reply]

In Section Seekers of Perl Wisdom