[Intl] Improved bundle reader implementations#11907
Conversation
1ce58ac to
c43fc14
Compare
|
👍 |
|
Of course, tests should be fixed first and CS issues fixed. |
There was a problem hiding this comment.
You can use ternary operator $array = ($array instanceof \ArrayAccess) ? $array->offsetGet($index) : $array[$index];
There was a problem hiding this comment.
I wonder why I did this here.. need to check
5e61a1a to
8a3a164
Compare
|
Updated. |
There was a problem hiding this comment.
is it really internal while being at the root of the component ? this looks weird to me. Internal classes used for the building of ICU data only should probably be placed in a subnamespace, keeping the top-level of the component for the poublic API
There was a problem hiding this comment.
I'm going to remove this flag in 2.6, but I don't want anybody to rely on this code until I'm sure this class will stay as it is.
|
ping @symfony/deciders |
8a3a164 to
33ec940
Compare
33ec940 to
c3cce5c
Compare
This PR was merged into the 2.3 branch. Discussion ---------- [Intl] Improved bundle reader implementations | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - This PR extracts bundle reader improvements from #9206. The code is internal and used for resource bundle generation only, so I did not care about BC too much. Commits ------- c3cce5c [Intl] Improved bundle reader implementations
This PR was merged into the 2.3 branch. Discussion ---------- [Intl] Integrated ICU data into Intl component #1 | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #11447, #10807 | License | MIT | Doc PR | - This PR is an alternative implementation to #11884. It depends on ~~#11906~~ and ~~#11907~~ being merged first (~~these are included in the diff until after a merge+rebase~~ merged+rebased now). With this PR, the ICU component becomes obsolete. The ICU data is bundled with Intl in two different formats: JSON and the binary ICU resource bundle format (version 2) readable by PHP's `\ResourceBundle` class. For a performance comparison between the two, see my [benchmark](/webmozart/json-res-benchmark). ~~The data is contained in two zip files: json.zip (2.6MB) and rb-v2.zip (3.8MB). The handler~~ ```php \Symfony\Component\Intl\Composer\ScriptHandler::decompressData() ``` ~~needs to be added as Composer hook and decompresses the data after install/update.~~ The data is included as text/binary now. Git takes care of the compression. Before this PR can be merged, I would like to find out what the performance difference between the two formats is in real applications. For that, I need benchmarks from some real-life applications which use ICU data - e.g. in forms (language drop-downs, country selectors etc.) - for both the JSON and the binary data. You can force either format to be used by hard-coding the return value of `Intl::detectDataFormat()` to `Intl::JSON` and `Intl::RB_V2` respectively. I'll also try to create some more realistic benchmarks. If JSON is not significantly slower/takes up significantly more memory than the binary format, we can drop the binary format altogether. Commits ------- be819c1 [Intl] Integrated ICU data into Intl component
This PR extracts bundle reader improvements from #9206.
The code is internal and used for resource bundle generation only, so I did not care about BC too much.