Re: [RFC] Loosening heredoc/nowdoc scanner

If the syntax of heredocs/nowdocs is to be loosened, the biggest aspect I’d like to see addressed is indentation. I can certainly see how it would be nice to loosen the restrictions around the post-closing-token newline to allow easier use in places like array definitions, but, I’ve never run into that problem myself. I have, however, been annoyed by the indentation limitations, so much so that I could probably count with my fingers the number of times that I’ve used the construct in the couple million lines of PHP I’ve written — even though I *want* to use it about once a week. I just find the side-effect on code formatting, when used in a container structure (class, function, method, loop, whatever), to be more than I can handle. Look at this simple example from the docs to see what I mean: <http://php.net/manual/en/language.types.string.php#example-89> One of the key benefits of consistent indentation is that it allows very rapid visual navigation of code by nearly eliminating the need for reading until you’ve zoned in on the right section of code. To illustrate this very well, just try to visually identify the code structure in this old-school BASIC code: <http://www.atariarchives.org/basicgames/showpage.php?page=3> That this restriction warrants italicized text inside a pink warning box in the docs suggests both that lots of people bump into it and that it runs counter to the expectations of the language. Now, perhaps I’ve not felt constrained by the newline restriction simply because I so rarely get to use the construct at all because of the indentation restriction. That’s actually probably the case. So that idea is important to address, but I think it’s pointless to address without also addressing indentation. What if we could do something like this: function foo() { $string = <<< THEEND This is the document text. Any whitespace appearing in a column that’s before the starting token is automatically ignored for all lines. THEEND; A few particulars: * If the starting token appears immediately adjacent to the <<< sequence, then parsing is done according to existing rules (perhaps with the changes in the RFC). This both maintains BC and avoids issues where more or less whitespace is ignored when, for example, the variable is renamed. * Extending the original proposal, the closing token can be indented without concern. Align it with the starting token, with the assignment line, whatever. * The closing token could not appear within the text. I’ve not given this solution deep thought, so I’m sure there are problems I’m missing. But if there’s a good solution to the indentation restrictions, I think it would be a huge win. And with the AST-based parser, there may be solutions that are possible now that were previously impossible, which makes this a good time to reconsider the problem. -- Bob Williams SVP, Software Development Newtek Business Services, Inc. “The Small Business Authority” http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).