Commits
-------
fd78ec0 Fixed PhpDoc for Twig_TokenParserInterface and all other TokenParsers
Discussion
----------
Fixed PhpDoc for Twig_TokenParserInterface and all other TokenParsers
Commits
-------
7194b1a Added a notice in the `nl2br` filter documentation about the proper Twig version to use it
Discussion
----------
Added a notice in the `nl2br` filter documentation ...
... about the proper Twig version to use it (1.5)
Commits
-------
542e9e7 added getKeyValuePairs() on Twig_Node_Expression_Array
3f64f1d added test for hash keys
4bdb3a9 fixed tests
3b1f269 support any expression as hash key
Discussion
----------
Allow hash keys to be any expression
This allows hash keys to be any expression
---------------------------------------------------------------------------
by fabpot at 2011/12/07 02:08:19 -0800
I had not implemented this feature back then because I'm not sure it makes sense to support it in the context of a templating system. I'm still not convinced that this is useful.
Commits
-------
b26d69a removed bogus TSRMLS_CCs
Discussion
----------
Fix strict mode in extension when building in ZTS mode
This removes a few misplaced TSRMLS_CCs causing if() expressions to always evaluate to true. This caused twig_template_get_attributes to always behave as if strict mode were disabled.
Commits
-------
8255b8b Fix test for previous commit
834ce4c Fix loop increment on some for loops (fix#562)
Discussion
----------
Fix loop increment
PR for #562.
Commits
-------
9e6f285 fixed crash in twig_template_get_attributes when input is not an array or object
Discussion
----------
Fix crash in twig_template_get_attributes when input is not an array or object
This fixes a crash when the input of twig_template_get_attributes() is not an array or object, and strict mode is enabled.
---------------------------------------------------------------------------
by nikic at 2011/12/16 12:03:21 -0800
Could you maybe place the exception tests in a different method?
---------------------------------------------------------------------------
by arnaud-lb at 2011/12/16 12:13:35 -0800
This method already expects many of its inputs to cause an exception to be thrown (it tests getAttribute() in strict mode, and in many cases the attribute isn't defined). I don't see a real benefit from moving these tests in a separate method in this case.
Commits
-------
c920344 code style
50da1a2 don't modify function name
Discussion
----------
Fix crash in extension
This fixes a crash caused by `php_strtolower()` modifying its input. (Crashes on amd64, but not on x86 for me.)
Commits
-------
3bb822e . misspell function _twig_convert_encoding -> twig_convert_encoding
Discussion
----------
misspell function _twig_convert_encoding -> twig_convert_encoding
Located in _twig_escape_js_callback, the function call was misspelled and raised a PHP Fatal error: Call to undefined function _twig_convert_encoding() in ~/www/project/vendors/Twig/Extension/Core.php on line 585
Commits
-------
d41d10c simplification
2dbb420 moved hard-coded regexes
61986c1 shortcut for non-interpolated double quoted strings
062ed5c regex optimization
0e63abb integration tests for interpolated strings
773fff5 parser tests for interpolated strings
098634e parser support for interpolated strings
c8bba24 lexer tests for interpolated strings
a203686 lexer support for interpolated strings
0bd63dd stack lexer states
Discussion
----------
String interpolation syntax
This adds support for string interpolation:
```
{{ "foo #{ any expression here } bar" }}
```
I find string interpolation to be often more readable than concatenation, and doesn't have the precedence ambiguity of the concatenation operator:
```
Interpolation:
{{ "foo #{bar} baz" }}
{{ "foo #{1+2} baz" }}
{{ "foo #{1+2} baz"|escape }}
Concatenation:
{{ "foo "~bar~" baz" }}
{{ "foo "~(1+2)~" baz" }} extra parentheses
{{ ("foo "~(1+2)~" baz")|escape }} more extra parentheses
```
---------------------------------------------------------------------------
by nikic at 2011/11/12 12:41:54 -0800
Really nice idea. We should discuss the exact syntax though :) Dart for example uses `${expr}` for interpolation or `$name` if the expression is just a name. I think it makes sense to have a special short syntax for the name case, because it is the most common one.
---------------------------------------------------------------------------
by stof at 2011/11/12 13:06:51 -0800
@nikic could you comment on the PR instead of commenting on each commit individually ? it would make it easier to see what is concerned in the PR.
---------------------------------------------------------------------------
by arnaud-lb at 2011/11/12 14:22:14 -0800
@nikic Thanks for your review, I'll take care of your remarks.
For the syntax, I have no preference. I've taken this one because it has the same semantics. In Ruby and Coffeescript the `#{...}` allows any expression between the brackets. In PHP the expression in the `${...}` must start with a variable name. As you mentioned Dart's `${...}` seems to allow any expression.
---------------------------------------------------------------------------
by nikic at 2011/11/12 15:03:48 -0800
@arnaud-lb If Ruby and Coffeescript use this, the #{...} syntax should be okay. Especially as ${...} might be confusing for PHP developers as it has the semantics of variable variables in PHP.
@stof Thanks, will do so next time.
---------------------------------------------------------------------------
by damianb at 2011/11/12 15:38:31 -0800
@stof he doesn't need to - this is something github handles already. in the PR view, beside the "@nikic commented" bits, there's a set of links that shows where exactly the comment was in the format of commit sha, filename, and line inside the diff.
You can see for yourself right here, upper left:
---------------------------------------------------------------------------
by stof at 2011/11/13 01:20:38 -0800
@damianb The comment appears, but not the context in which the comment was. We have to follow each link to see it whereas comments done on the PR appear directly with their context. This is why I said it is easier when comments are on the PR.
---------------------------------------------------------------------------
by nikic at 2011/12/02 15:13:30 -0800
So what about this now?
Btw, `REGEX_STRING` and `REGEX_DQ_STRING_PART` still are hardcoded and do not depend on the specified `interpolation` tags. But this looks hard to change, at least the regexes are quite complicated.
---------------------------------------------------------------------------
by arnaud-lb at 2011/12/02 15:22:45 -0800
I think I've addressed all issues (except hardcoding of `#{` and `}` in `REGEX_STRING` and `REGEX_DQ_STRING_PART`.)
Can this be merged after v1.4 is release if the syntax is accepted ?
---------------------------------------------------------------------------
by nikic at 2011/12/03 01:53:41 -0800
This would be my go for `STRING` and `DQ_STRING_PART` (isn't tested):
```php
<?php
$interpolChar = preg_quote(substr($options['interpolation'][0], 0, 1), '/');
$interpolPart = '[^' . $interpolChar . '"\\\\]*';
if (strlen($options['interpolation'][0]) > 1) {
$interpolRest = preg_quote(substr($options['interpolation'][0], 1), '/');
$interpolRegex = $interpolPart . '(?:(?:\\\\.|' . $interpolChar . '(?!' . $interpolRest . '))' . $interpolPart . ')*';
} else {
$interpolRegex = $interpolPart . '(?:\\\\.' . $interpolPart . ')*';
}
$this->options['dq_string_part_regex'] = '/' . $interpolRegex . '/As';
$this->options['string_regex'] = '/"' . $interpolRegex . '"|\'([^\'\\\\]*(?:\\\\.[^\'\\\\]*)*)\'/As';
```
It should allow both a single char interpolation syntax (like `{`) and multichar ones (like `#{`).
By the way, could we maybe move the compiled regexes out of `$this->options` into `$this->regexes`?
Fabien Potencier
Eugene Serkin
Javier Eguíluz
Arnaud Le Blanc
nikic
JEDIBC
