Commits
-------
22e9036 updated CHANGELOG
bafe890 [FrameworkBundle] changed Client::enableProfiler() behavior to fail silently when the profiler is not available (it makes it easier to write functional tests)
f41872b [FrameworkBundle] added a way to enable the profiler for the very next request in functional tests (closes#4307)
67b91e5 [HttpKernel] added a way to enable a disable Profiler
Discussion
----------
[2.2] added a way to enable the profiler for the very next request in a functional test
Bug fix: yes/no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4307
Todo: -
License of the code: MIT
Documentation PR: should be done before merging
After merging this PR, we need to disable the profiler in the test environment in Symfony SE.
Commits
-------
6ff9b04 Add Luhn validator
Discussion
----------
[2.2] [Validator] Add Luhn validator
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
Todo: Adding documentation if this PR is blessed.
License of the code: MIT
I submitted these validators to JMSPaymentCoreBundle, because they're payment related, but @schmittjoh feels that they're a better choice for adding to Symfony2.
See schmittjoh/JMSPaymentCoreBundle#52 for the original submission.
---------------------------------------------------------------------------
by fabpot at 2012-07-04T05:19:42Z
I'm +1. @bschussek?
---------------------------------------------------------------------------
by shieldo at 2012-07-04T15:46:05Z
+1 in principle (certainly the Luhn check). I did wonder whether Visa Electron should also be in there (although, that uses a subset of the Visa range, and the chance that you would be checking for a Visa Electron but *not* Visa at the same time is vanishingly small, so maybe this is unnecessary).
---------------------------------------------------------------------------
by merk at 2012-07-04T21:25:30Z
@shieldo I did have a concern about the Electron as well, but in the case of an online system doing payment processing, I'm not sure anyone would ever need to check if it was an Electron card or not.
---------------------------------------------------------------------------
by merk at 2012-07-04T21:28:25Z
We could expand the CardScheme stuff further with this list: http://en.wikipedia.org/wiki/List_of_Issuer_Identification_Numbers
Is there any point expanding the validator beyond financial services and into the other sevices listed?
---------------------------------------------------------------------------
by shieldo at 2012-07-04T21:37:41Z
@merk Yes, in actuality there are always going to be cases you can't trap with a regex - I'd say validation like this is working if it catches a majority of cases of invalid numbers, because in reality ones that get through will just fail downstream anyway. The purpose of the validator isn't to identify individual schemes for numbers, it's to do a sanity check across collections of schemes.
I don't really see any point expanding beyond financial services for a core validator (imho) - I'm not sure how stable some of this information is.
---------------------------------------------------------------------------
by Gator92 at 2012-07-11T00:45:50Z
+1 on the Luhn check (without the authorship, just give credit to Greg Knapp), the CardScheme, however, is not really required by most gateways these days, it's a better candidate for a custom constraint.
---------------------------------------------------------------------------
by merk at 2012-07-11T00:47:20Z
I dont object, but Greg's algorithm has a flaw for odd length creditcard numbers. The unit testing written by Infinite caught this.
---------------------------------------------------------------------------
by Gator92 at 2012-07-11T01:35:46Z
You're right, the Knapp algo is flawed and does not appear to work on odd-numbered length cards.
---------------------------------------------------------------------------
by fabpot at 2012-07-11T05:49:22Z
@merk: Can you open two new pull requests? One for each validator?
---------------------------------------------------------------------------
by merk at 2012-07-26T23:42:24Z
PR updated to remove CardScheme into its own PR.
Documentation PR added to symfony-docs
* 2.1:
Create CONTRIBUTING.md file for auto-linking in PR's
Added Bulgarian translation
[Profiler]Use the abstract method to get client IP
Typo fix
Fixing incorrect word in twig:lint command description
Rename $key parameter to $name for consistency
=Minor chnage: replaced function by method
Fixed the phpdoc in the DependencyInjection component
Commits
-------
71d8148 Create CONTRIBUTING.md file for auto-linking in PR's
Discussion
----------
Create CONTRIBUTING.md file for auto-linking in PR's
See: https://github.com/blog/1184-contributing-guidelines
---------------------------------------------------------------------------
by kbond at 2012-09-17T17:35:26Z
@jmikola won the race
---------------------------------------------------------------------------
by stof at 2012-09-17T17:37:35Z
and this should be updated according to the discussion on the dev mailing-list
---------------------------------------------------------------------------
by fabpot at 2012-09-17T17:42:28Z
Instead of duplicating the information, I would just linked to the documentation.
---------------------------------------------------------------------------
by jmikola at 2012-09-17T18:42:29Z
I reduced the file to the "Contributing" block from the readme.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-17T19:36:36Z
+1
Commits
-------
de6658b [Profiler]Use the abstract method to get client IP
Discussion
----------
[Profiler]Use the abstract method to get client IP
---------------------------------------------------------------------------
by armetiz at 2012-09-17T13:37:19Z
This PR is also done for master branch : https://github.com/symfony/symfony/pull/5527
Commits
-------
2bcb6f2 Fixing incorrect word in twig:lint command description
Discussion
----------
[TwigBundle} Fixing incorrect word in twig:lint command description
Commits
-------
c2f8563 Rename $key parameter to $name for consistency
Discussion
----------
[DependencyInjection] Rename $key parameter to $name for consistency
When I worked on #5478, I noticed an inconsistency in parameter naming in the ```ParameterBag#remove``` method. This PR brings things in line with the rest of the class.
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
Commits
-------
02516de [Routing] fix variable with a requirement of '0'
1f5b793 [Routing] fix setting empty requirement in Route
Discussion
----------
[Routing] fix setting empty requirement
First commit: A requirement of "^$" was overlooked and wasn't recognized as empty after stripping it in Route.
Second commit: Fixes a requirement of '0' that was ignored by the Compiler.
Commits
-------
8f46795 tests for HeaderBag
Discussion
----------
tests for HeaderBag
Hi,
This patch adds 100% tests coverage for HeaderBag.
Best regards,
Michal
Commits
-------
622102e [Process] change all documentation type to callable
Discussion
----------
[Process] change all documentation type to callable
Update documentation per #5456 instead of mixing in with restart() pull request.
Commits
-------
690e28e Convert parameter name to lowercase when removing an element from ParameterBag
Discussion
----------
[DependencyInjection] Convert parameter name to lowercase when removing an element from ParameterBag
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5477
License of the code: MIT
---------------------------------------------------------------------------
by sstok at 2012-09-10T08:42:30Z
👍
---------------------------------------------------------------------------
by fabpot at 2012-09-10T09:28:16Z
Shouldn't it be done on the 2.0 branch?
---------------------------------------------------------------------------
by stloyd at 2012-09-10T09:29:35Z
@fabpot AFAIK `2.0` don't have `ParameterBag#remove()` method
---------------------------------------------------------------------------
by aderuwe at 2012-09-10T09:29:52Z
The remove method is not present in 2.0.
On Mon, Sep 10, 2012 at 11:28 AM, Fabien Potencier <notifications@github.com
> wrote:
> Shouldn't it be done on the 2.0 branch?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/5478#issuecomment-8418300>.
>
>
Commits
-------
be28e56 [Routing] disallow numeric named variables in pattern
Discussion
----------
[Routing] compile check for numeric named variables in pattern
Because PHP raises an error for such subpatterns in PCRE and thus would break matching, e.g. this is not allowed as regex `(?<123>.+)`.
So add a compile time check for a non-working pattern like '/{123}'.
---------------------------------------------------------------------------
by sstok at 2012-09-06T08:31:42Z
Strangely enough Regex buddy gives no warning or error with the pattern.
Is the name all numeric invalid or just the beginning?
1e4 and 0xFF would be perfectly valid but returns true with is_nummeric()
---------------------------------------------------------------------------
by Tobion at 2012-09-06T08:59:07Z
Any numeric is not valid. I guess this limitation is unique to PHP's binding to PCRE.
I think it's because the returned matches array of of preg_match contains both the subpattern as integer index and as named variable. So having a numeric named variable would conflict as `array['1'] === array[1]`.
Commits
-------
7c5cfeb [Routing] added test why #5238 is not that easy
Discussion
----------
[Routing] added test why #5238 is not that easy
This just adds a test that wasn't covered yet and shows why #5238 is not that easy as I thought at first.
Commits
-------
0f86a33 micro-optim: replace for with foreach
4efb9fe [Form] Remove unneeded FormUtil constants
Discussion
----------
[Form] Remove FormUtil constants
The constants are not useful from outside the class as the $pluralMap is also private. So no need to expose these veriables in the API when they cannot be used in any way. Unfortunately there are not private constants, so use private static. Then I realized the variables can be removed altogether, as they are only used once anyway and the index meaning is already documented in pluralMap.
---------------------------------------------------------------------------
by empire at 2012-08-18T12:58:22Z
FormUtils is abstract class, and maybe subclass (in future) will use this constants, I think changing access modifier to `protected` is better option.
---------------------------------------------------------------------------
by Tobion at 2012-08-18T12:59:40Z
They cannot, as pluralMap is private...
---------------------------------------------------------------------------
by Partugal at 2012-08-18T14:11:17Z
extract self::$pluralMap into local variable add small speed up
4.5499801635742 ms vs 5.7430267333984 ms on 100 iterations
---------------------------------------------------------------------------
by Tobion at 2012-08-18T14:16:47Z
This is not about performance.
---------------------------------------------------------------------------
by Partugal at 2012-08-18T14:21:11Z
yes but adds
your changes vs current is
5.7430267333984 ms vs 6.4971446990967 ms on 100 iterations
---------------------------------------------------------------------------
by Tobion at 2012-08-18T14:29:48Z
How about `$map =& self::$pluralMap[$i]`?
---------------------------------------------------------------------------
by Partugal at 2012-08-18T14:59:57Z
I mean https://gist.github.com/3387253
---------------------------------------------------------------------------
by Partugal at 2012-08-18T15:01:45Z
foreach is event faster :)
(4.1971206665039 ms on my hw)
---------------------------------------------------------------------------
by Tobion at 2012-08-18T15:04:51Z
I see.
---------------------------------------------------------------------------
by Partugal at 2012-08-18T15:06:41Z
in first comment i mean code like this:
```php
$pluralMap = self::$pluralMap; // do this because access to static property is to slow
```
on my machine & is slower `$map =& $pluralMap[$i]` vs `$map = $pluralMap[$i]`
5.0 vs 4.8 ms
imho & not needed in read only code
---------------------------------------------------------------------------
by Tobion at 2012-08-18T15:15:03Z
Well, you'd need to benchmark memory too. `=&` should reduce memory primarily in this case.
---------------------------------------------------------------------------
by Partugal at 2012-08-18T15:19:35Z
```php
echo memory_get_usage() . "\n"; // 711536
$a = array_fill(5, 6000, 'banana');
echo memory_get_usage() . "\n"; // 1497632
$b = $a;
echo memory_get_usage() . "\n"; // 1497760
$b[1] = 2;
echo memory_get_usage() . "\n"; // 2283832
```
1497760 - 1497632 = 128 it is size for variable structure not for its value:
```php
echo memory_get_usage() . "\n"; // 711536
$a = 1;
echo memory_get_usage() . "\n"; // 1497632
$b = &$a;
echo memory_get_usage() . "\n"; // 1497760
```
---------------------------------------------------------------------------
by Seldaek at 2012-08-18T17:52:32Z
@Tobion http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html - search for "copy-on-write" if you don't want to read it all.
---------------------------------------------------------------------------
by Tobion at 2012-08-18T19:37:44Z
Yeah I know about copy on write. I thought there might be a difference what you assign a sub-element of an array to a variable. But apparently not.
Interestingly `$a =& $b` takes a little more memory than `$a = $b` according to `memory_get_usage ()` but not when using `memory_get_usage (true)`.
---------------------------------------------------------------------------
by bschussek at 2012-08-30T08:15:01Z
I don't like the removal of the constants. They introduce meaning into the integers and improve code clarity. The rest looks good.
---------------------------------------------------------------------------
by Tobion at 2012-08-30T13:18:19Z
My opinion of the constants:
- They are part of the public API (as const are alwalys public) but cannot be used at all, as everything else is private...
- They are each only used once.
- The meaning of the indices is already documented in `$pluralMap`
- They are not used when building `$pluralMap` so they dont imprivate code clarity and consistence either. But doing so would on the other hand make it probably more ugly. So removing them is IMO best solution.
---------------------------------------------------------------------------
by bschussek at 2012-08-30T15:21:03Z
If you really need to remove the constants, then please comment the code where they are used accordingly.
---------------------------------------------------------------------------
by Tobion at 2012-08-31T00:58:51Z
I dont see what I should comment to make it more understandable, as the the map is already assigned to a named variable like `$suffixLength = $map[1];`.
---------------------------------------------------------------------------
by bschussek at 2012-08-31T09:12:18Z
> I dont see what I should comment to make it more understandable, as the the map is already assigned to a named variable
`$map[2]` and `$map[3]` is not self-describing.
---------------------------------------------------------------------------
by Tobion at 2012-08-31T17:23:15Z
@bschussek Done.
---------------------------------------------------------------------------
by bschussek at 2012-08-31T22:13:41Z
Could you please squash your commits?
Commits
-------
05f7f78 Fixed the phpdoc in the DependencyInjection component
Discussion
----------
Fixed the phpdoc in the DependencyInjection component
I was sick of having a warning in my IDE each time I used DefinitionDecorator because of an invalid phpdoc in the constructor, so I took some time and fixed it in the whole DI component.
---------------------------------------------------------------------------
by stof at 2012-09-07T23:09:04Z
The travis failure is unrelated. It is all about some intl failures.
---------------------------------------------------------------------------
by eventhorizonpl at 2012-09-07T23:37:04Z
Reviewed-by: Michal Piotrowski <michal@eventhorizon.pl>
---------------------------------------------------------------------------
by pborreli at 2012-09-08T01:42:26Z
👍