/--- On Fri, Aug 04, 2000 at 05:58:44PM +0100, Piers Cawley wrote:
| > At 02:31 PM 8/4/00 +0200, dLux wrote:
| > > My suggestion is: declare "eval $scalar" as a bad guy.
| > It's not just string eval. It's also do FILE and require.
| > It's a powerful construct, though, and I wouldn't declar
At 01:30 AM 8/5/00 +0900, Simon Cozens wrote:
>On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote:
> > At 02:31 PM 8/4/00 +0200, dLux wrote:
> > > My suggestion is: declare "eval $scalar" as a bad guy.
> >
> > It's not just string eval. It's also do FILE and require.
>
>Which you need
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 02:31 PM 8/4/00 +0200, dLux wrote:
> > My suggestion is: declare "eval $scalar" as a bad guy.
>
> It's not just string eval. It's also do FILE and require.
>
> It's a powerful construct, though, and I wouldn't declare it as evil.
> Possibly as "u
On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote:
> At 02:31 PM 8/4/00 +0200, dLux wrote:
> > My suggestion is: declare "eval $scalar" as a bad guy.
>
> It's not just string eval. It's also do FILE and require.
Which you need at runtime, even in compiled code, to run external
confi
At 02:31 PM 8/4/00 +0200, dLux wrote:
> My suggestion is: declare "eval $scalar" as a bad guy.
It's not just string eval. It's also do FILE and require.
It's a powerful construct, though, and I wouldn't declare it as evil.
Possibly as "unimplemented on some platforms (read: palm)" or "The
op
>Hello!
> I am thinking about the perl compiler, and I thought if somebody
>avoid using the "eval $scalar", the compiled code (perl to C
>compiled code) may not contain a full perl interpreter. If it is the
>case, we must say to any module developer: Don't use "eval $scalar"!
>
Hello!
I am thinking about the perl compiler, and I thought if somebody
avoid using the "eval $scalar", the compiled code (perl to C
compiled code) may not contain a full perl interpreter. If it is the
case, we must say to any module developer: Don't use "eval $scalar"!
This s
