On Thu, Sep 15, 2011 at 16:51, Nikita Popov <nikita....@googlemail.com> wrote: > Hi Hannes, thanks for your response! > > On Thu, Sep 15, 2011 at 9:22 AM, Hannes Magnusson > <hannes.magnus...@gmail.com> wrote: >> the change to ext/tokenizer/tests/token_get_all_variation16.phpt seems >> really weird? > I changed the test to not include a __halt_compiler statement anymore, > as it didn't make sense in this context, and included a function call > instead. The file would have been just a parse error, as > __halt_compiler can only occur in the outermost scope or in namespace > declaration score. Additionally the behavior of token_get_all on > __halt_compiler is already tested in the other test (bug54089.phpt), > so I though it wasn't necessary to test it there again. > >> And I'm unsure how this should actually work. >> >> A file containing: >> <?php >> >> __halt_compiler() >> >> ?> >> stuff >> >> Will return "stuff" after this patch.. that doesn't seem expected. > First of all: The second patch (the _full one) isn't that important to > me, as you can fetch the data after __halt_compiler(); quite easily in > userland code, too (concat all tokens and calculate the offset from > that, then substr it from the code). So if you think it doesn't make > sense, I would be okay without it. The original reasoning was, that > fetching the contents after __halt_compiler(); is the most probable > thing you want to do if you are using token_get_all on a file with
Wait wait wait. Thats the point here? __COMPILER_HALT_OFFSET__ already tells you where the data starts. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
