On Mon, Oct 02, 2000 at 09:17:31PM -0500, David L. Nicol wrote:
> Jarkko Hietaniemi wrote:
>
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar o
Jarkko Hietaniemi wrote:
> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq(). For example doubling the $ and @?
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().
>
> I have wanted that also, although I don't remem
Nathan Wiger wrote:
> I don't know about this. What if someone writes:
>
>print "You owe me $2, $name.\n";
>
> With -w it'll print out the "correct" version?
With a warning, because $2 isn't defined.
>You owe me $2, Nate.
>
> But without it it won't?
>
>You owe me , Nate.
You turn
> > This would HAVE to be a very optional feature. I rely on undef
> > converting to a null string in many, many programs.
>
> Surely in those programs you don't have -w turned on, because you wouldn't
> want to see all those warning messages. So here is another idea: -w causes
> string interpol
Eric Roode wrote:
> >Imagine that you could easily override the conversion of undef() into a
> >string, so that when stringified it returns something like "#UNDEF#"
> >instead of just an empty string. That would make debugging far more
> >easy: take a look at the output, and search for this senti
>Imagine that you could easily override the conversion of undef() into a
>string, so that when stringified it returns something like "#UNDEF#"
>instead of just an empty string. That would make debugging far more
>easy: take a look at the output, and search for this sentinel string.
This would HAV
Mark-Jason Dominus wrote:
>
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().
>
> I have wanted that
On Wed, 13 Sep 2000 13:56:53 -0700, Peter Scott wrote:
>I would rather solve this by requiring that Perl identify the thing that
>was undef than what you propose below. Surely it can't be that hard.
Fine by me.
Only, AFAIK, Perl is only aware of "values", not of "variables".
--
Bart
> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq().
I have wanted that also, although I don't remember why ju
At 10:49 PM 9/13/00 +0200, Bart Lateur wrote:
>Imagine the following scenario: your script contains a doiuble-quotish
>40 line here-doc, with a bunch of variables in it. Unforetunately, you
>forgot to set one, and you get the not so helpful complaint:
>
> use of unitialized value at line x
On Wed, Sep 13, 2000 at 10:49:41PM +0200, Bart Lateur wrote:
> Imagine the following scenario: your script contains a doiuble-quotish
> 40 line here-doc, with a bunch of variables in it. Unforetunately, you
> forgot to set one, and you get the not so helpful complaint:
>
> use of unitialize
Imagine the following scenario: your script contains a doiuble-quotish
40 line here-doc, with a bunch of variables in it. Unforetunately, you
forgot to set one, and you get the not so helpful complaint:
use of unitialized value at line xxx
where xxx is the line number for the line that c
13 matches
Mail list logo
