Commits
-------
beb4fc0 [WIP][Locale] StubIntlDateFormatter::parse was throwing exception instead of returning Boolean false like intl implementation
b61dff7 fixed CS
Discussion
----------
[WIP][Locale] StubIntlDateFormatter::parse was throwing exception instead of returning Boolean false like intl implementation
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: 
Fixes the following tickets: #2781
Todo: A test fail in 32 bit environment, executed tests only with PHP 5.3.2 and ext-intl ICU 4.2 based
Failed test:
1) Symfony\Tests\Component\Locale\Stub\StubIntlDateFormatterTest::testFormatWithDefaultTimezoneIntl
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'1969-12-31 21:00:00'
+'1969-12-31 16:00:00'
The regexp in MoneyType doesn't work if currency format has no decimal
(like JPY) and doesn't work either if the currency symbol is unicode
This change fixes both issues and adds a unit test
Commits
-------
7e14a56 [Locale] Removed unneccesary semi-colon
cacc880 [Bugfix][Locale] Fixed incomplete Locale data loading
Discussion
----------
[Bugfix][Locale] Fixed incomplete Locale data loading
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass:  Fixes the following tickets: #3090
Todo: -
Sublocales like de_CH returned only incomplete results for
getDisplayCountries(), getDisplayLanguages() and getDisplayLocales(),
consisting only of results specific for this sublocale, but without the
results of their respective parent locale
This PR was https://github.com/symfony/symfony/pull/3106 before - reopened it as a new PR because the commits were too chaotic.
Sublocales like de_CH returned only incomplete results for
getDisplayCountries(), getDisplayLanguages() and getDisplayLocales(),
consisting only of results specific for this sublocale, but without the
results of their respective parent locale
Commits
-------
7961014 [Yaml][Parser] changes according review
efce640 [Yaml][Parser] throw an exception if not readable
Discussion
----------
[Yaml][Parser] throw an exception if service file not readable.
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3077
Todo: -
---------------------------------------------------------------------------
by makasim at 2012-01-13T15:49:49Z
@fabpot done
Commits
-------
fe62401 optimized string starts with checks
Discussion
----------
optimized string starts with checks
Doing this with strpos() is slightly faster than substr().
```
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
---------------------------------------------------------------------------
by vicb at 2012-01-11T19:58:27Z
How faster ? even if the string is long and do not contain an occurrence of the sub-string ?
Looks like micro-(not)-optimizations to me.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-11T20:04:26Z
The difference is about 0.1s when repeated 1M times.
---------------------------------------------------------------------------
by vicb at 2012-01-11T20:08:12Z
% would be better (machine & env independant), what string size, what match offset ?
I personally vote against (`substr` is more meaningful to me and I do not like micro-optims)
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-11T20:12:34Z
I personally consider this a coding standard but don't want to bikeshed here :)
---------------------------------------------------------------------------
by vicb at 2012-01-11T20:28:08Z
I have [tried](https://gist.github.com/1596588) at home.
`strpos ` **is** faster unless you have a very long string, probably because you do not need to create a new string, interesting, thanks for the tip.
---------------------------------------------------------------------------
by Tobion at 2012-01-11T22:40:18Z
I think strpos() is more useful. Say you want to change the string you have to replace 2 variables (the text and the length parameter) when using substr(). It could also introduce bugs when they don't match. With strpos() it's only the text.
---------------------------------------------------------------------------
by robocoder at 2012-01-11T22:43:22Z
alternate micro-optimization that doesn't create a temporary string:
```
strncmp($v, "@", 1) === 0
```
---------------------------------------------------------------------------
by Tobion at 2012-01-11T22:47:12Z
@robocoder probably the fastest solution but needs to be benchmarked
Commits
-------
7f7f82a [HttpKernel] removed unnecessary regex
Discussion
----------
[HttpKernel] removed unnecessary regex
The pattern was also flawed because of the unescaped `.`
```
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
Commits
-------
7f7c2a7 Add prof-of-concept test, this test will fail without changes in previous commit
253eeba [BugFix][Validator] Fix for PHP incosistent behaviour of ArrayAccess
Discussion
----------
[BugFix][Validator] Fix for PHP incosistent behaviour of ArrayAccess
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2779
Todo: -
[](http://travis-ci.org/canni/symfony)
Because PHP function `array_key_exists` is buggy, it works great with native
PHP `ArrayObject` instances, but hand written implementations of `ArrayAccess`
and `Traversable` objects will fail to work with `CollectionValidator`
Tests from second commit are valid use cases, but without this change, they will fail.
Commits
-------
aa58330 [Form] fixed flawed condition
Discussion
----------
[Form] fixed flawed condition
The validate() method always returns an object. The test is whether there are violations in that object.
```
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
```
---------------------------------------------------------------------------
by fabpot at 2012-01-10T21:22:10Z
What about removing the if condition altogether?
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T21:23:55Z
This way we avoid creating an `ArrayIterator` for no reason.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2779
Todo: -
Because PHP function `array_key_exists` is buggy, it works great with native
PHP `ArrayObject` instances, but hand written implementations of `ArrayAccess`
and `Traversable` objects will fail to work with `CollectionValidator`
Commits
-------
8ee9161 [Security] Adding more extensive PHPDoc to UserInterface, AdvancedUserInterface and UserProviderInterface
Discussion
----------
More extensive PHPDoc for Security interfaces
Hey guys!
We've started to get into the habit of documenting interfaces and methods in the official docs. I think these things should be omitted from the documentation entirely, and replaced with a link to API docs that rock (I've started doing this already).
This PR just takes some of the details we have in the docs and pushes them back as PHPDoc. I use `@see`, `<code>` and changed a particular `@throws` to have a FQ class name since there's no `use` statement.
Thanks!
---------------------------------------------------------------------------
by weaverryan at 2012/01/07 20:24:15 -0800
Ok, updated and I think it's clearer now.
---------------------------------------------------------------------------
by fabpot at 2012/01/07 23:29:45 -0800
@weaverryan Great! I think that's a really good idea to document interfaces in the API, that makes a lot of sense.
---------------------------------------------------------------------------
by maastermedia at 2012/01/08 02:10:04 -0800
+1 Symfony API needs that atention also, yes. Thank you.
---------------------------------------------------------------------------
by lsmith77 at 2012/01/08 11:45:04 -0800
@fabpot: but then we should also add a list of interfaces to the API http://screencast.com/t/vu4Tljkri0
Commits
-------
9441c46 [DependencyInjection] PhpDumper, fixes#2730
Discussion
----------
[DependencyInjection] PhpDumper, fixes#2730
Hey, this PR fixes#2730, if no parameters are set, the constructor wont get passed a ParameterBag
Bug fix: yes (#2730)
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
3rd and last try ;) this time i think its all fine
Commits
-------
85ca8e3 ParameterBag no longer resolves parameters that have spaces.
99011ca Added tests for ParameterBag parameters with spaces
Discussion
----------
[DependencyInjection] Parameters with spaces are not resolved
Bug fix: yes
Feature addition: no
Backwards compatibility break: no (not likely, according to convention)
Symfony2 tests pass: yes
Fixes the following tickets: #2884
`ParameterBag` currently resolves anything between two `%` signs, which creates issues for any parameters in the DIC that are legitimate text. This PR enforces the [documented parameter convention](http://symfony.com/doc/2.0/book/service_container.html#service-parameters) so that only `%parameters.with.no_spaces%` are resolved.
I was considering using instead `^%([^\w\._-]+)%$`, but felt that was too constricting & could easily introduce issues with existing applications.
Commits
-------
3f2e1b0 [Console] Updated tests to reflect the change from `program` to `application`
2b64944 [Console][Output] Fixed some minor typos and grammatical errors
96997f1 [Console][Input] Added missing PHPDoc and fixed some minor typos and grammatical errors
855b8af [Console][Helper] Added missing PHPDoc and fixed some minor typos and grammatical errors
3ad02bd [Console][Formatter] Added missing PHPDoc @throws and fixed some minor typos and grammatical errors
33e3f11 [Console] Added a missing PHPDoc and replaced `program` by `application`
Discussion
----------
[Console] Fixed and completed PHPDoc
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
* Fixed minor typos and grammatical errors
* Added missing PHPDoc for some methods
* Added missing @throws
Commits
-------
e417153 [BugFix][Console] Fix type hint for output formatter
Discussion
----------
[BugFix][Console] Fix type hint for OutputFormatter in OutputStream constructors
I consider this as a bug, cause it disables ability to change formatter implementation
BugFix: yes
Feature addition: no
Sysmfony2 test pass: yes
---------------------------------------------------------------------------
by fabpot at 2011/12/18 00:23:05 -0800
It's not a bug fix as existing code that extend these classes will now fail.
---------------------------------------------------------------------------
by stof at 2011/12/18 03:51:38 -0800
@fabpot does the constructor enforces its signature for child classes ? I don't think so.
Commits
-------
1e370d7 typo fix
93d8d44 added some more infos about Config
27efd59 added READMEs for the bridges
34fc866 cosmetic tweaks
d6af3f1 fixed README for Console
6a72b8c added basic README files for all components
Discussion
----------
added basic README files for all components and bridges
heavily based on http://fabien.potencier.org/article/49/what-is-symfony2 and the official Symfony2 documentation
---------------------------------------------------------------------------
by jmikola at 2011/11/03 13:36:07 -0700
Great work. For syntax highlighting on the PHP snippets, you could add "php" after the three backticks.
---------------------------------------------------------------------------
by lsmith77 at 2011/11/03 13:41:29 -0700
done
---------------------------------------------------------------------------
by stealth35 at 2011/11/03 13:49:31 -0700
Nice job, but you also need to add `<?php`
ex :
``` php
<?php
use Symfony\Component\DomCrawler\Crawler;
$crawler = new Crawler();
$crawler->addContent('<html><body><p>Hello World!</p></body></html>');
print $crawler->filter('body > p')->text();
```
---------------------------------------------------------------------------
by lsmith77 at 2011/11/03 13:56:57 -0700
done
---------------------------------------------------------------------------
by ericclemmons at 2011/11/03 19:57:57 -0700
@lsmith77 Well done! This makes consumption of individual components that much easier, *especially* now that `composer.json` files have been added.
---------------------------------------------------------------------------
by lsmith77 at 2011/11/04 01:18:23 -0700
ok .. fixed the issues you mentioned @fabpot
---------------------------------------------------------------------------
by lsmith77 at 2011/11/11 15:00:27 -0800
@fabpot anything else left? seems like an easy merge .. and imho there is considerable benefit for our efforts to spread the word about the components with this PR merged.
---------------------------------------------------------------------------
by drak at 2011/11/11 18:54:13 -0800
You know, it might be a nice idea to put a link to the documentation for each component if there is some at symfony.com
---------------------------------------------------------------------------
by lsmith77 at 2011/11/12 00:59:14 -0800
i did that in some. but i might have missed a few places.
On 12.11.2011, at 03:54, Drak <reply@reply.github.com> wrote:
> You know, it might be a nice idea to put a link to the documentation for each component if there is some at symfony.com
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/2561#issuecomment-2715762
---------------------------------------------------------------------------
by breerly at 2011/11/21 10:28:36 -0800
Pretty excited with this.
---------------------------------------------------------------------------
by dbu at 2011/11/24 00:02:50 -0800
is there anything we can help with to make this ready to be merged?
---------------------------------------------------------------------------
by lsmith77 at 2011/12/18 02:39:23 -0800
@fabpot: seriously .. if you are not going to deliver something "better" and don't provide a reason what is wrong with this .. then its beyond frustrating. i obviously do not claim that these README's are perfect (and certainly still no replacement for proper documentation), but I do claim that in their current form they are a radical step forward to potential users of the Symfony2 components.
Commits
-------
5c41ec9 [HttpKernel][Client] Only simple (name=value without any other params) cookies can be stored in same line, so lets add every as standalone to be compliant with rfc6265
Discussion
----------
[HttpKernel][Client] Set cookie fix
Bug fix: yes
Feature addition: no
Backwards compatibility break: no(?)
Symfony2 tests pass: yes
Fixes the following tickets: #2881
Only simple cookies can be stored in same line:
* Used by now (__wrong__): `Set-Cookie: name1=value, name2=value`
* Proper according to RFCs: `Set-Cookie: name1=value; name2=value`
So lets add every as standalone ([next header](http://tools.ietf.org/html/rfc6265#section-3.1)) to be compliant with [RFC6265](http://tools.ietf.org/html/rfc6265). This fixes#2881.
Previously, Boolean defaults were printed as strings, which lead to true and false being printed as "1" and "", respectively. With this change, they are now printed as "true" and "false".
Commits
-------
cd24fb8 change explode's limit parameter based on known variable content
b3cc270 minor optimalisations for explode
Discussion
----------
[FrameworkBundle][CssSelector][HttpFoundation][HttpKernel] [Security][Validator] Minor optimizations for "explode" function
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
I added limit parameter in some places, where it may be usefull. I did not check the context of what values may have been exploded. So to not break anything, I added +1 to limit parameter.
If you find out that in some places limit (or limit+1) is not important or meaningless, write a comment please and I will fix it.
---------------------------------------------------------------------------
by fabpot at 2011/12/07 06:56:49 -0800
Adding +1 just to be sure to not break anything is clearly something we won't do. What is the benefit of doing that anyway?
---------------------------------------------------------------------------
by pulzarraider at 2011/12/07 13:50:24 -0800
The main idea of making this PR was to notify about some places that may run faster with just adding one parameter to explode function.
If in code is someting like: ```list($a, $b) = explode(':', $s);```
Function ```explode``` will create n-items (depends on ```$s```), but we need in code only the first two items. There is no reason to let ```explode``` create more items in memory that are NEVER used in our code. The limit parameter is there for these situations, so let's use it.
I know that it is microoptimization and may look unimportant, but we are writing a framework - so people expect that code will be as fast as possible without this kind of mistakes.
As I've noticed above, I know that +1 is not ideal solution, but the fastest without debugging the code. I expect that someone (with good knowledge of that code) will look at it and write in comments if variable may contain 1 comma (dot or someting on what is doing the explode) or maybe 2 in some situations or more.
Anyway, +1 will not break anything, because same items are created as it is now, but no unnecessary item is created.
---------------------------------------------------------------------------
by fabpot at 2011/12/07 23:14:59 -0800
I'm +1 for adding the number to avoid problems but I'm -1 on the optimization side of things as it won't optimize anything.
---------------------------------------------------------------------------
by helmer at 2011/12/08 12:46:49 -0800
*.. The main idea of making this PR was to notify about some places that **may** run faster ..*
I am also unsure the optimization is really an optimization, care to benchmark (with meaningful inputs)? As for the limit+1 thing, why would you want to +1 it? The number of ``list`` arguments should always reflect the ``limit`` parameter, no?
---------------------------------------------------------------------------
by pulzarraider at 2011/12/08 23:11:34 -0800
@helmer please try this simple benchmark:
```
<?php
header('Content-Type: text/plain; charset=UTF-8');
define('COUNT', 10000);
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc:dddddddddddddddddddddd:eeeeeeeeeeeeeeeeeeeeeeeee:fffffffffffffffffffffffffff';
$start = microtime(true);
for ($i = 0; $i < COUNT; $i++) {
list($a, $b) = explode(':', $source_string);
}
$end = microtime(true)-$start;
echo 'without limit: '.$end."\n";
$start = microtime(true);
for ($i = 0; $i < COUNT; $i++) {
list($a, $b) = explode(':', $source_string, 2);
}
$end = microtime(true)-$start;
echo 'with limit: '.$end."\n";
```
My results are:
```
without limit: 0.057228803634644
with limit: 0.028676986694336
```
That is 50% difference (with APC enabled). Of course the result depends on the length of source string and if it's too short, the difference may be none or very very small. That's why I said, that it **may** run faster and is just a micro optimization.
---------------------------------------------------------------------------
by pulzarraider at 2011/12/08 23:18:12 -0800
@helmer And why +1? It depends on a code:
```
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc';
list($a, $b) = explode(':', $source_string, 2);
var_dump($a, $b);
```
and
```
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc';
list($a, $b) = explode(':', $source_string, 3);
var_dump($a, $b);
```
gives different results. That's why the content of the variable must be known.
---------------------------------------------------------------------------
by helmer at 2011/12/09 00:08:28 -0800
@pulzarraider Thanks for the benchmark, seems like a gain enough. Although, we are more likely having a scenario of:
``explode(':', 'a🅱️c')`` vs ``explode(':', 'a🅱️c', 3)`` with a ``COUNT`` of 10, where the difference is not even in microseconds anymore :)
The limit addition alters the behaviour though, ie suddenly you can define a controller [logical name](http://symfony.com/doc/current/book/routing.html#controller-string-syntax) as ´´AcmeBlogBundle:Blog:show:something``, and things go downhill from there on.
All that aside, I'm +1 for setting the limit to the exact number of ``list`` parameters, but certainly not number+1, this is just too wtfy (as you said, this was a safety thing, but I reckon for this PR to be merged it needs to be +0).
---------------------------------------------------------------------------
by drak at 2011/12/09 08:28:58 -0800
Overall `list()` is ugly as it's not very explicit. Even though it would mean extra lines, it's better to `explode()` then explicitly assign variables:
```
$parts = explode(':', $foo);
$name = $parts[0];
$tel = $parts[1];
```
`list()` is one of those bad relics from the PHP past...
---------------------------------------------------------------------------
by fabpot at 2011/12/11 10:07:47 -0800
@drak: why is `list` not explicit? It is in fact as explicit as the more verbose syntax you propose.
---------------------------------------------------------------------------
by pulzarraider at 2011/12/11 13:08:50 -0800
@drak: I agree with @fabpot. In speech of benchmarks ```list``` is faster then using a helper variable.
@fabpot, @helmer I've changed explode's limit to be correct (without +1) and removed some changes from this PR, where I can't find out what the content of variable may be. Unit tests pass, so I think it's ready for merge.
Commits
-------
3759ff0 [Locale] StubNumberFormatter allow to parse 64bit number in 64bit mode
Discussion
----------
[Locale] StubNumberFormatter allow to parse 64bit number in 64bit mode
Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/stealth35/symfony)
Fixes the following tickets: #2735
---------------------------------------------------------------------------
by stealth35 at 2011/12/01 06:47:32 -0800
@Seldaek should be better now
---------------------------------------------------------------------------
by stealth35 at 2011/12/02 04:22:42 -0800
@fabpot done
---------------------------------------------------------------------------
by fabpot at 2011/12/02 04:28:24 -0800
Tests do not pas for me (on a Mac):
1) Symfony\Tests\Component\Locale\Stub\StubNumberFormatterTest::testParseTypeInt64StubWith64BitIntegerInPhp64Bit
->parse() TYPE_INT64 does not use true 64 bit integers, using only the 32 bit range.
Failed asserting that 2147483648 matches expected -2147483648.
.../tests/Symfony/Tests/Component/Locale/Stub/StubNumberFormatterTest.php:819
---------------------------------------------------------------------------
by stealth35 at 2011/12/02 04:50:20 -0800
@fabpot, could you send me the return of this code
``` php
<?php
$formatter = new \NumberFormatter('en', \NumberFormatter::DECIMAL);
$value = $formatter->parse('2,147,483,648', \NumberFormatter::TYPE_INT64);
var_dump($value);
$value = $formatter->parse('-2,147,483,649', \NumberFormatter::TYPE_INT64);
var_dump($value);
```
---------------------------------------------------------------------------
by fabpot at 2011/12/02 06:06:21 -0800
int(-2147483648)
int(2147483647)
---------------------------------------------------------------------------
by stealth35 at 2011/12/02 06:10:28 -0800
It's nosens, but the Stub should follow Intl ... so I fix that
---------------------------------------------------------------------------
by stealth35 at 2011/12/11 08:48:25 -0800
It's OK now
