John Williams wrote:
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
John Williams wrote:
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
With all of the new crazy quoting shenanagains, I'm not sure that the
"balenced brackets are fine" rule will still be possible; and thus end
delimeters will always need to be escaped. For instance, imagine
what a nightmare this would be to parse:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]}]]]] blah];
Sure, anyone who writes something like this deserves to be shot;
however, if the "balanced brackets are ok" rule still stands, the
above code would be legal. (And I really, really, really don't
want the above code to be legal ;)
Well, just don't do it then. With or without balanced brackets, the
obfuscating programmer can do the above; he just needs more or less
backslashes.
Saying "Just don't do it" doesn't stop someone from doing it. True,
the example was an obfuscated one, but it was to prove a point. This is
just as obfuscated in my opinion:
$var = qq[[[%hash{qq[one]}{qq[next]}],[],[%hash{qq[hi]}{qq[there]}]]];
Adding backslashes to the first example helps clear up some of the
confusion:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi\]]}]\]]\]blah];
$var = qq[blah \[\q[blah \[\qq[%hash{qq[\[hi\]]}]\]]\]blah];
Maybe that's because you wrote it in the first place; as a reader I think
it looks just as bad, if not worse.
True, it looks *very* bad, but least its easier to tell what
quotes and what doesn't.
Really, I think that if you really feel the need to use a delimiter
that you know that will be in the text that you are quoting, you should
have to go through the trouble of escaping it. Its only fair :)
No, it's not fair, because I ALWAYS have to worry about escaping
something. What I really want is a quote operator which really quotes
everything. I don't want to have to worry about what accidental "\q"
substrings are going to do in my strings. q{} was the best way to do that
in perl5, because even braces within the string were ok if they behaved
themselves.
What's wrong with single quoted here-docs?
'\qq[]' is the real source of evil here.
Actually the apocalypse says:
RFC 226: Selective Interpolation in Single Quotish Context.
This proposal has much going for it, but there are also difficulties,
and I've come close to rejecting it outright simply because the
single-quoting policy of Perl 5 has been successful.
Maybe if we pushed Larry a bit, he could reject it after all?
Why? I love \qq[] and \q[]. I'd much rather have embedded strings
than be able to balance used delimiters inside quotes. I don't like the
"balance delimeters" rule at all, and don't see it as anything more
than an ugly hack. I'd much rather have it go than embedded strings.
I am diametrically opposed to your opinions here. I hate '\qq[]' as an
ugly hack, which ruins the non-embedding, non-quoting nature of
non-interpolated strings. If you want to embed, just use interpolated
strings.
Don't forget that the backslash is already special in
non-interpolating strings; I don't think that adding a single
special case will make things too confusing.
What if \q[] was allowed in interpolated strings, but not in
non-interpolated strings. Then I'm happy with that non-interpolated
strings really don't interpolate, and you might be happy because it would
only make sense to do one level of nesting. ie, you cannot embed \qq[]
inside \q[]. Or you could do $(''), which is the same number of
characters as \qq[], and doesn't require introducing
yet-another-new-rule-to-an-already-too-complicated-escaping-system.
I think \qq[] is the much more useful of the two, so
that really doesn't help much.
Joseph F. Ryan
[EMAIL PROTECTED]
