Re: RFC 229 (v2) Variable interpolation on demand.
On Fri, 29 Sep 2000 15:30:46 -0500, David L. Nicol wrote:
>it's not a new feature. It's amazing the subtle control you
>can get with s/(\$...)/$1/ge depending on your
>
>Wrapping such a critter up in a tied scalar sounds like a total
>piece of cake
What will you do with:
${foo}bar
$hash{blah}
$ary[blah]
\xFE
\123
\n\t
etc?
Some huge piece of cake.
--
Bart.
Re: RFC 229 (v2) Variable interpolation on demand.
"David L. Nicol" wrote: > > > > This is a new feature, so name conflict is the only issue. > > > > Thisseems compatiblewith otherextensionsto string > > interpolation... whatever extensions get implemented should work here > > too. > > it's not a new feature. It's amazing the subtle control you > can get with s/(\$...)/$1/ge depending on your Hmm. I'll have to think about your expression some more, it is not immediately obvious how it achieves the goal of the RFC, but I differ with your semantics regarding the word feature. The RFC describes a new feature. The functionality is not new, but the feature makes the functionality more accessible in simpler ways. > Wrapping such a critter up in a tied scalar sounds like a total > piece of cake Perhaps. If you do the wrapping, please forward. I have no experience yet with tie. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 229 (v2) Variable interpolation on demand.
"John L. Allen" wrote:
> On 29 Sep 2000, Perl6 RFC Librarian wrote:
>
> > Make Perl's powerful string interpolation facilities are available to
> > variables, in addition to literals.
> >
> > =head1 DESCRIPTION
> >
> > Given:
> >
> > $foo = 'def';
> > $bar = 'ghi';
> > $x = "abc$foo$bar";
> > $y = 'abc$foo$bar';
> >
> > There is no way to turn obtain the value of $x from the value of $y.
> > In other words, while $foo and $bar were interpolated into $x, they
> > were not interpolated into $y. It would be nice to get Success! from:
>
> Um, what would your proposal gain you over
>
> $z = eval "qq{$y}";
>
> other than conciseness, elegance and speed (which may be quite enough!) ?
Correctness. Your solution fails if $y contains '}' characters. This was
noted in the next version, which I froze. The cost of prechecking to choose
an appropriate delimiter, which if $y contains at least one instance of all
legal characters may not even exist, could be enormous (compared to the cost
of the operation) and unsuccessful.
That said, your solution works if the set of possible content of $y is
sufficiently constrained.
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: RFC 229 (v2) Variable interpolation on demand.
Robert Mathews wrote:
>
> "David L. Nicol" wrote:
> > it's not a new feature. It's amazing the subtle control you
> > can get with s/(\$...)/$1/ge depending on your
>
> You mean /gee, right? Hadn't thought of that. /ee makes my brain hurt.
I actually usually do things like
undef $/;
$template = `cat template`; #rude open
$template =~ s/\[(\w+)\]/$UserVariables{$1}/g;
to avoid the security concerns. /gee is correct for simple interpolation,
although how to match even curlies is a headache. Someone has proposed
a regex primitive to match a syntactically correct statement, for use in such
cases -- is it an RFC?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"A taste so good that we stand behind every bottle and can."
Re: RFC 229 (v2) Variable interpolation on demand.
"David L. Nicol" wrote: > it's not a new feature. It's amazing the subtle control you > can get with s/(\$...)/$1/ge depending on your You mean /gee, right? Hadn't thought of that. /ee makes my brain hurt. -- Robert Mathews Software Engineer Excite@Home
Re: RFC 229 (v2) Variable interpolation on demand.
> > This is a new feature, so name conflict is the only issue. > > Thisseems compatiblewith otherextensionsto string > interpolation... whatever extensions get implemented should work here > too. it's not a new feature. It's amazing the subtle control you can get with s/(\$...)/$1/ge depending on your Wrapping such a critter up in a tied scalar sounds like a total piece of cake tie $InterpolateMeOnDemand, Glenn::IterpolOnDemanPlain, 'foo$foobar$bar';
Re: RFC 229 (v2) Variable interpolation on demand.
On Fri, 29 Sep 2000, Robert Mathews wrote:
> "John L. Allen" wrote:
> > Um, what would your proposal gain you over
> >
> > $z = eval "qq{$y}";
> >
> > other than conciseness, elegance and speed (which may be quite enough!) ?
>
> $y = '};system "rm -rf *";qq{';
Hmmm, hold on a second while I test that... NOT! :-)
John.
Re: RFC 229 (v2) Variable interpolation on demand.
"John L. Allen" wrote:
> Um, what would your proposal gain you over
>
> $z = eval "qq{$y}";
>
> other than conciseness, elegance and speed (which may be quite enough!) ?
$y = '};system "rm -rf *";qq{';
--
Robert Mathews
Software Engineer
Excite@Home
Re: RFC 229 (v2) Variable interpolation on demand.
On 29 Sep 2000, Perl6 RFC Librarian wrote:
> Make Perl's powerful string interpolation facilities are available to
> variables, in addition to literals.
>
> =head1 DESCRIPTION
>
> Given:
>
> $foo = 'def';
> $bar = 'ghi';
> $x = "abc$foo$bar";
> $y = 'abc$foo$bar';
>
> There is no way to turn obtain the value of $x from the value of $y.
> In other words, while $foo and $bar were interpolated into $x, they
> were not interpolated into $y. It would be nice to get Success! from:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
John.
