On Mon, 15 Mar 2010, David E. Wheeler wrote:
> 
> On Mar 15, 2010, at 10:57 AM, Ricardo Signes wrote:
> 
> > Is there anyone who can provide a reading of the spec to support the change?
> > Do you (David) remember what part of the spec convinced you?
> 
> When I made the change, I wasn't aware of the spec, but based the
> change on `perlpod`, particularly this bit:
> 
> >            C<<< $a <=> $b >>>
> >            C<<<<  $a <=> $b     >>>>
> >
> >        And they all mean exactly the same as this:
> >
> >            C<$a E<lt>=E<gt> $b>
> >
> >        As a further example, this means that if you wanted to put these bits
> >        of code in "C" (code) style:
> >
> >            open(X, ">>thing.dat") || die $!
> >            $foo−>bar();
> >
> >        you could do it like so:
> >
> >            C<<< open(X, ">>thing.dat") || die $! >>>
> >            C<< $foo−>bar(); >>
> >
> >        which is presumably easier to read than the old way:
> >
> >            C<open(X, "E<gt>E<gt>thing.dat") || die $!>
> >            C<$foo−E<gt>bar();>
> 
> My interpretation of that was that any angle brackets inside should be
> considered literal, and thus escaped. The whole point of `<< >>`
> AFAICS was to allow one to use literal brackets without escaping them,
> as one must do in `<>`.

It is really just about not having to escape the *closing* '>' because you
could always include '<' without escaping unless it was ambiguous with the
start of another formatting sequence.

And anyways, I doubt there are many documents that would want to show
literal POD formatting sequences inside a C<< >> block (if we ignore the
POD specs and documentation of POD modules themselves for a moment). So
it seems generally much more useful to still be able to use nested
formatting while simultaneously not having to escape most '<' and '>'
characters.

Cheers,
-Jan

Reply via email to