Re: [PHP-DEV] function autoloading v4 RFC
On August 15, 2024 5:22:51 PM GMT+02:00, Rob Landers wrote: >Hello internals, > >I've decided to attempt an RFC for function autoloading. After reading >hundreds of ancient (and recent) emails relating to the topic along with >several abandoned RFCs from the past, and after much review, I've decided to >put forth a variation of a previous RFC, as it seemed the least ambitious and >the most likely to work: > >https://wiki.php.net/rfc/function_autoloading4 > >Please let me know what you think. An implementation should be along before >opening it for a vote (now that I realize how important that is). > >— Rob Hello, I've also noted that on another RFC, but I think it applies here too: Any new constants that are shaped like an enum and used like an enum should just be an actual enum. I think instead of `SPL_AUTOLOAD_CLASS` and `SPL_AUTOLOAD_FUNCTION`, there should be an `enum AutoloadType` (to be bikeshed), and the new parameters should be typed as such, instead of `int`. Regards, Mel
Re: [PHP-DEV] Re: Decoding HTML and the Ambiguous Ampersand
On August 16, 2024 2:59:11 AM GMT+02:00, Dennis Snell wrote: > >All, > > >I have submitted an RFC draft for including the proposed feature from this >issue. Thanks to everyone who helped me in this process. It’s my first RFC, so >I apologize in advance for any mistakes I’ve made in the process. > > >https://wiki.php.net/rfc/decode_html > > > > >This is proposed for a future PHP version after 8.4. > > >Warmly, >Dennis Snell > Hello, I have just one nit: I think it would be better to use an enum for the `$context` parameter rather than a constant. It also feels like it ought to be nice to find some reasonable default... I'm sure many programmers will see this parameter and be unsure which value to use. There should, at the very least, be clear documentation with real-world examples in which cases which one should be used. All in all, this is definitely a welcome improvement! Regards, Mel
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
>From: Anton Smirnov >Date: Sun, 3 Mar 2024 at 19:56 > >Greetings! > >As I know some session-related middlewares force custom-only session_id >handling by setting > > use_cookies = Off > use_only_cookies = On > >and then using session_id(...) directly > >Example: >https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137 > >I think if you're making this hack impossible, you should provide an >alternative non-hackish way to do this. > >Maybe just keep use_cookies = Off > >A wild idea: > >1) Add a temporary config > > # by default; current behavior; > # throws a deprecation right from the introduction > cookies.use_post_get = On > # do not set the session from POST and GET > cookies.use_post_get = Off > >Remove it in 9 with the rest > >2) keep use_cookies in PHP 9 with the updated meaning > >I don't think it's a good solution but maybe it can spark a better one > >Best, >Anton I think the better option is to make this explicit and add a config along the lines of `automatic_session_detection` (name to be bikeshed) defaulting to `On`, and in your use-case setting it to `Off` explicitly. Regards, Mel
Re: [PHP-DEV] RFC [Discussion]: Make unserialize() emit a warning for trailing bytes
On 27 March 2023 20:20:58 CEST, "Michał Marcin Brzuchalski" wrote: > Personally, I'd like the unserialize to throw an exception if trailing >bytes are detected. >If not by default then with the use of the option passed to unserialize >function. If that's the desired direction, it makes more sense to emit a deprecation notice now and throw an exception starting in 9.0. Regards, Mel Dafert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
On 14 September 2022 21:39:36 CEST, "Tim Düsterhus" wrote: >Hi > >On 9/13/22 19:58, Mel Dafert wrote: >> - Deciding that `max_input_vars` is not relevant anymore and should be >> handled by the likes of Apache and NGINX, thus changing the default to >> `0` and removing the setting >> over a deprecation period. > >This would be my preferred option, but my understanding is that the limit >still is relevant to protect against attacks on the hash table implementation. >The web server can't really protect against this type of attack, because the >payload required to execute the attack is fairly small. Protecting against the >attack without some arbitrary cut-off limit would require making the hash >algorithm used for the superglobals dependent on a randomly generated >per-request seed value. I can't comment on how easy or hard that would be to >change, but I believe that this should be the ultimate goal here. It's also >what other programming languages do. > >Best regards >Tim Düsterhus Thank you, this makes a lot of sense to me. I assume that this rules out that option, at least for now, unless someone makes the relevant changes to the hashing. But this also means that aborting the request would be just as effective at protecting such an attack as truncating. Would aborting instead of truncating introduce any new attack surface? The only thing I could think of would be a DoS vector, but I believe there are a lot of ways you can get a server to instantly abort your request... Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
On 14 September 2022 16:44:33 CEST, Thomas Nunninger wrote: >Hi, > >> In summary, I believe this can only be solved inside of PHP itself, by >> allowing to configure a way for `max_input_vars` to abort the request >> instead of truncating the input. >> The options I see feasible are: >> - A new ini setting `max_input_vars_abort` (default to 0), which, if set to >> 1, will abort the request if there are more input variables than allowed. >> - A method to reliably detect whether the input vars were truncated (eg. >> `function has_post_been_truncated(): bool`), so the application can decide >> whether to abort or not. >> - Deciding that `max_input_vars` is not relevant anymore and should be >> handled by the likes of Apache and NGINX, thus changing the default to `0` >> and removing the setting >> over a deprecation period. >> >> I am leaning towards the first option, but would be open to either outcome. > >I'd prefer that PHP aborts such requests. Then data loss/inconsistency is >prevented for everybody and people can fix their applications. (So no need for >an ini setting that allows acting in "danger mode".) > >If you'd like to give developers more options to choose from, I'd go for >max_input_vars_abort (default 1) plus has_post_been_truncated(): That way the >behavior is safe from the start. And people who opt in for "danger mode" can >reliably detect if there was some data loss and can deal with it. > >Regards >Thomas > That's a fourth option that I had overlooked: Just changing the behaviour to always abort, without the option to truncate. This would certainly be acceptable to me. Is there anyone relying on the truncating behavior? It's hard for me to imagine such a situation. This question also determines whether this would be acceptable to go into 8.3, or if we would need to wait for 9. Is something like this considered a breaking change? This reasoning would also affect your second proposal - changing the default is similarly a breaking change if there are people relying on it, albeit a little easier to fix. If people think it would be okay, then I would strongly prefer option 4, as then there's no need for bikeshedding on ini settings or new global functions. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
On 13.09.22 20:29, Jordan LeDoux wrote: On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert wrote: (This happens in the legacy application I am working on, I do not see it changing anytime soon.) All of these solutions would be available in some future version of PHP. While your situation highlights something that might be broadly applicable to PHP, you'd likely have to update the legacy application to take advantage of any solution that was eventually included so that it could run on the most recent version of PHP. Unless you're suggesting that this would also be backported? 7.4 falls out of all support in a few months. Just want to make sure you're aware of how the inclusion process would work for any solution to this issue. Jordan Hello, I am aware that this will not help me immediately - I already put some hack in there that combines multiple of the given detection options and hopes for the best. I am not arguing for this to be backported, the third option would probably only change any default in PHP9 (but give me the knowledge that I can safely set `max_input_vars` to 0 everywhere). However, the application is on its way towards being ported to PHP8, and mostly runs already. But just because I ported all of the backend code doesn't mean I was able to clean up any frontend code (or overly complex forms) at the same time. If any of my proposed options make it into 8.3, I do think it is realistic that I could use that solution in a two years or so (and sleep safely knowing that none of my forms containing multiselects will (almost) silently truncate data). Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Error behaviour for max_input_vars
Hi internals, I recently ran into issues with the ini setting `max_input_vars`. By default, it will truncate input variables in `$_POST` etc. to the first 1000, and issue a E_WARNING. The form I was using had an extremely big multiselect, where in one case around 1000 options were actively selected, each selected option being sent to the server as a separate `my_select[]` POST variable. The select was the final field in the form, thus is was not immediately noticed when `max_input_vars` truncated options from the select. I have since changed `max_input_vars` to a higher value, but there was nevertheless an unknown amount of data loss in the meantime. I would have strongly preferred if the request had been aborted with an error, instead of issuing a warning and continuing with incomplete data. However, I could not find a way to reliably detect a way that input variables had been truncated. There are some suggested solutions in [1], but all of them have downsides: - Counting variables inside `$_POST`: If there are multiple variables with the same name (without `[]` at the end), they will be counted for `max_input_vars`, but only show up once in `$_POST`. (This happens in the legacy application I am working on, I do not see it changing anytime soon.) - Checking `php://input`: This is not possible if the request uses `multipart/form-data`. - Checking `error_get_last()` for the warning: This seems extremely brittle - even if currently there is no other warning thrown at startup, if that changes in the future, this might break. - Custom error handler using `set_error_handler()`: This is not possible, as the warning is thrown before any PHP code can run (and register the handler). If I missed a reliable method, I would be thankful, and this email can be ignored. In summary, I believe this can only be solved inside of PHP itself, by allowing to configure a way for `max_input_vars` to abort the request instead of truncating the input. The options I see feasible are: - A new ini setting `max_input_vars_abort` (default to 0), which, if set to 1, will abort the request if there are more input variables than allowed. - A method to reliably detect whether the input vars were truncated (eg. `function has_post_been_truncated(): bool`), so the application can decide whether to abort or not. - Deciding that `max_input_vars` is not relevant anymore and should be handled by the likes of Apache and NGINX, thus changing the default to `0` and removing the setting over a deprecation period. I am leaning towards the first option, but would be open to either outcome. Regards, Mel Dafert [1]: https://stackoverflow.com/questions/12169818/in-php-how-can-i-detect-that-input-vars-were-truncated-due-to-max-input-vars-be -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
On 16 June 2022 09:10:08 CEST, Pierrick Charron wrote:
> [...]
>- For consistency expose the new Curl URL API as functions mapped one to
>one to libcurl functions :
>
>function curl_url(?string $url = null): CurlUrl|false {}
>function curl_url_set(CurlUrl $url, int $part, string $content, int $flags
>= 0): bool {}
>function curl_url_get(CurlUrl $url, int $part, int $flags = 0):
>string|false {}
>function curl_url_errno(CurlUrl $url): int {}
>function curl_url_strerror(int $error_code): ?string {}
>
>- Add methods to the CurlUrl object to make it less opaque and expose an
>object oriented style API. I would keep it minimal and let userlanAd API
>provide higher level APIs as guzzle for example. (You can see the current
>implementation [5])
>
>final class CurlUrl implements Stringable
>{
>public function __construct(?string $url = null) {}
>public function get(int $part, int $flags = 0): string {}
>public function set(int $part, string $content, int $flags = 0): void {}
>public function getErrno(): int {}
>public function __toString(): string {}
>public function __clone() {}
>}
Hello,
When IntlDatePatternGenerator was implemented, I initially also supplied both
a procedural and OO-style API, but was told that this duplication was historical
and not necessary for new APIs.
See the thread following this message: [1]
I would argue that this also applies to curl, and that it might make sense to
only
supply the OO-style API here as well.
(With `curl_url_strerror` being exposed as either a static method on `CurlUrl`
or as `getErrorMessage`, I suppose.)
>- It would also be nice to add this object oriented API for existing
>CurlHandle, CurlMultiHandle and CurlShareHandle classes. For example the
>CurlHandle class would look like that (First implementation [6])
I think this would be a good idea either way.
Regards,
Mel
[1] https://externals.io/message/114473#114658
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
>> In one application recently I actually had the string "false" (coming >> from a form transmission) being passed to a boolean argument and leading >> to true, which definitely was unintended. > >But "false" is a perfectly sensible thing to pass as a string in an >API (as HTTP is a string based protocol). As is 'faux' if your API is >used by French speaking programmers. > >You need an layer of code that converts from strings to the precise >types your API needs, rather than just passing values straight >through. In my opinion, this is a good point in the RFC's favour, as the depreciation warning will show up in exactly those places where this conversion layer was erroneously missing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] NULL Coercion Consistency
On 7 May 2022 12:54:45 CEST, Craig Francis wrote: >I will note that my RFC does not change NULL coercion (why I quoted the >documentation), and I'm not against the other BC breaks where certain type >coercions are clearly problematic. > >It was 8.1 which introduced this specific BC problem (with ignorable >deprecation notices)... and while that change was to begin alignment with user >defined functions, it's the user defined functions that have been the oddity >(i.e. do not use NULL coercion, unlike other contexts, such as concatenation, >== comparisons, arithmetics, sprintf, print, echo, array keys). Personally I >think it should have been user defined functions that worked with the "old and >well known" coercion rules, and doing so would have reduced complexity (i.e. >working in the same way). ... >But my focus is on upgrading existing code, and this one is difficult to find >and update (e.g. the lack of tooling to help). It is exactly user-defined functions that this RFC introduces breakage for. The behaviour to throw on null in user-defined functions exists since PHP 7.0, and is being relied on. Changing these now would introduce behaviour changes that are harder to find than new type errors. Using strict typing isn't an option either/would be just as much work as auditing the changes this would introduce. It may be that user-defined functions should have accepted null to begin with in your opinion, but that still makes it a breaking change now. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Stricter implicit boolean coercions
>I see, so as long as there are no bool type hints for function parameters
>everything would be the same.
>
>This would lead to a minor asymmetry for
> $preserve = "yes";
> if ($preserve) # Silently working, true
> array_slice($array, $offset, preserve_keys: $preserve));
> # Not working any more
>
>I assume your solution would be to add an explicit cast to bool? i.e.
>something along the lines of
> array_slice($array, $offset, preserve_keys: (bool)$preserve));
> # Explicit cast to silence implicit conversion
>
>I'm a bit worried about having to keep two different convert-to-bool rule sets
>in mind (implicit vs. explicit) and about the additional casts.
There are already two different convert-to-bool rule sets for
array|object|resource|null, where they will be accepted in `if` but rejected
when
passed to a function taking a bool param:
```
$x = (object) ['a'=> 1];
if ($x) {
echo "if\n";
}
function takes_bool(bool $param) {}
takes_bool($x); // throws TypeError
```
https://3v4l.org/fCQFL
Adding string|float to that list doesn't seem to be that big of a difference
here.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] NULL Coercion Consistency
On 8 April 2022 19:34:52 CEST, Craig Francis wrote:
>Hi,
>
>I've written a new draft RFC to address the NULL coercion problems:
>
>https://wiki.php.net/rfc/null_coercion_consistency
>
>This is due to the result of the Allow NULL quiz:
>
>https://quiz.craigfrancis.co.uk/
>
>14 votes for Fatal Type Errors irrespective of `strict_types=1`;
>13 votes for NULL coercion when not using `strict_types=1`;
>8 votes to update some parameters to allow NULL;
>
>I appreciate some want to force strict type checking on everyone, but I
>want to make sure we have this properly documented, with names, and
>explanations.
>
>Breaking changes should be justified - if they aren't, they only
>make upgrading difficult and frustrating (bad for security).
>
>Craig
Hello,
While the RFC extensively documents the problem space, it's rather short on what
exactly it proposes.
In particular, does this propose changing user-defined functions under
strict_types=0 to accept null for scalar types?
Eg., this will be allowed (under strict_types=0):
```
function x(string $y, int $z) {
...
}
x(null, null); //no error, no warning
```
Regards,
Mel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for RFC to remove undefined array index warning when used ina ternary
>Hi, > >In PHP, you can write `$array['a']['b']['c'] ?? 'default';`. It works when >either null or inexistant index is encountered at any depth of the expression. > >—Claude You're right, I did not know that. Thank you. That basically replaces the need for my proposal, then. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal for RFC to remove undefined array index warning when used ina ternary
On 27 February 2022 00:04:58 CET, Kamil Tekiela wrote:
>I just wanted to add that the following
>
>$name = $_POST['name'] ?: 'Default Name';
>
>with existence check would be
>
>$name = $_POST['name'] ?? null ?: 'Default Name';
>
>You don't need empty().
>
>I would be against changing the behaviour of elvis/ternary operator.
>However, I remember seeing past suggestions to implement another operator.
>One that would fill the gap between null-coalesce and elvis operators. If I
>recall correctly, most of the time, these proposals end in consensus that
>such operator isn't really needed. See
>https://externals.io/message/89292#89292 and
>https://externals.io/message/101606#101610
>Maybe, it would be worthwhile to refresh a discussion about adding such
>operator to the PHP language?
I think that what would be needed here is another proposal from this discussion,
something like a null-safe operator but for array access.
From a different thread about this:
On 15 February 2022 16:50:48 CET, Rowan Tommins wrote:
>I seem to remember someone proposing an explicit operator for "this array
>dimension might not exist", something like this:
>
>if ( $array[?'key'] === true )
>
>Which would translate to:
>
>if ( (array_key_exists('key', $array) ? $array['key'] : null) === true )
I would propose to extend this still to mean:
`if((($array !== null && array_key_exists('key', $array)) ? $array['key'] :
null) === true)`
This combines the above proposal with the behaviour of the nullsafe operator
`?->`, allowing to signal that the array may be null or that the key may not be
set.
This allows the requested functionality without warnings/notices:
$name = $_POST[?'name'] ?? 'Default Name';
But also allows accessing arrays with multiple, possibly defined dimensions:
$val = $array[?'a'][?'b'][?'c'] ?? 'default';
Currently, the last example would need to be a rather unwieldy ternary:
$val = (isset($array['a']) && isset($array['a']['b']) &&
isset($array['a']['b']['c']) ? $array['a']['b']['c'] : 'default';
The fact that the new syntax would also allow $array to be null may be
undesirable in some cases, but I don't know if we can define the semantics in a
better way.
(Also, in some cases this may actually be useful, eg. when mixing ?-> and the
new
[?...] syntax.)
I am not sure if the exact syntax/semantics proposed here are the best
solution, but I would argue that the fact that this seems to be a recurring
topic
calls for a solution in that general direction.
Regards,
Mel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension 4.0
On 24 February 2022 09:47:39 CET, Go Kudo wrote: > >Hi > >RFC has been updated. Is this up to the required standard? >https://wiki.php.net/rfc/rng_extension > >I acknowledge that the previous RFC may have been difficult to discuss. If >the problem has been solved, I would like to make another ML-wide >announcement and wait for two weeks from there. > >I added PCG64 because according to the RNG experts, there seems to be a >mild conflict between Xorshiro256 and PCG64. Also, as mentioned in the RFC, >Rust and NumPy also implement PCG64. > >In order to verify the feasibility of PCG64, we created a PoC in C. So far, >it seems to work fine. >https://github.com/zeriyoshi/pcg64_example > >Regards, >Go Kudo Hello, Two small nits: - The "Backward Incompatible Changes" section is missing the fact that `\Random\Randomizer` will be reserved. - In the definition of `Randomizer` in the "Proposal" section, there is a typo: `function getBytes(int $legnth)` should be `$length` instead. To me, this RFC looks very good so far - I don't have a vote however. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Multibyte strings
On 11 February 2022 07:26:45 CET, "Michał" wrote: >Hi everyone. >It's a known fact that nowadays most websites use at least UTF-8 >encoding. Unfortunately PHP itself has stopped a bit in the previous >century. Is there any reason why the mbstring extension cannot be >introduced to core in the next major version (maybe preceded with a >deprecation message like it was with the mysql extension in v5)? All >functions from the standard library would become aliases for multibyte >equivalents. As others have said, any change to behaviour in something as subtle as string encoding makes little sense (see PHP 6 or the mess that was the migration from Python 2 to 3, which did exactly that). However, I do see an argument to be made to make the mbstring extension always available, similar to what was done with the json extension [1]. Currently, one cannot assume to have access to things like mb_strcut, which makes writing code that does not break when it's fed UTF-8 relatively complicated. Frameworks like Drupal also require mbstring for anything other than English content [2]. The manual [3] also says that it does not require any external libraries, so there does not seem to be any technical obstacle either. Would that be an option? Or am I missing some obvious reason that mbstring should not be always available, like licensing issues? Regards, Mel [1] https://wiki.php.net/rfc/always_enable_json [2] https://www.drupal.org/docs/system-requirements/php-requirements#s-mbstring- [3] https://www.php.net/manual/en/mbstring.requirements.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Adding `final class Deque` to PHP
On 1 February 2022 17:06:59 CET, Stephen Reay wrote: > >The proposed API switches between terms `front`, `back`, `start` and `end` in >comments - is there meant to be a conceptual difference between front/start >and end/back ? On a similar note, why are the methods for getting the first/last value called `top()`/`bottom()`? Off the top of my head, it is hard for me to imagine which side is the top and which side is the bottom. I would prefer if it was called something more intuitive, possibly `first()`/`last()` in accordance with `array_key_first()`/`array_key_last()`. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
Hello internals,
>register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
>register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
>register_operator(*, function (int $lhs, Foo $rhs): int { ...});
>
>But this just brings a new set of problems, including visibility issues
>(i.e. can't use private fields in the implementation), and the fact that
>this requires executing a function at runtime rather than being defined at
>compile time.
Since this is going deeply into magic land anyways, we could go another step
further
and make this a builtin/"macro" that does happen at compile-time, but also can
impose additional restrictions on what is
allowed - namely, that the registered function must not be inlined but a static
method on one of the arguments.
For example: (syntax completely imaginary here but slightly inspired by rust):
register_operator!(+, lhs: Bar, rhs: Foo, ret: Bar, Bar::addFooBar);
register_operator!(+, lhs: Bar, rhs: Bar, ret: Bar, Bar::addBar);
register_operator!(+, lhs: int, rhs: Bar, ret: int, Bar::addBarInt);
register_operator!(+, lhs: Foo, rhs: int, ret: Foo, Foo::addFooInt,
commutative: true);
with
class Bar {
...
public static addFooBar (Bar $bar, Foo $foo): Bar { }
// etc.
}
Advantages:
- Explicitly named methods that can be called/tested separately
- Slightly improved searchability - grepping "register_operator" will show all
operator
combinations inside a code base
- Cannot implement operators for arbitrary classes that one does not own - the
method
must be from one of the operands
- Multiple distinct methods per operand/class without full method overloading
- No restrictions around having scalar types only as rhs
If I am not mistaken, the engine should also be able to typecheck the methods
to ensure that the types are correct, and additionally also be able to disallow
overlaps (eg. defining Foo+Bar commutitatively as well as Bar+Foo),
which should throw an error as soon as the second definition is encountered.
Disadvantage: This sounds like a lot of work to implement, and I am not sure
if the checks are even possible the way I'm imagining them (with classes being
loaded on demand, etc.).
Also, this syntax would definitely need work, I just wanted to point out that
on the
drawing board, many of these design problems are solvable.
Whether they are worth the effort, and whether this is a good idea at all, is
left
for others to decide.
Regards,
Mel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Is there an RFC/discussion for ::class being a specific type?
On 16 November 2021 23:02:59 CET, Kamil Tekiela wrote: >Hi Dusk, > >Perhaps, you misunderstood me. Take a look at the documentation >https://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class >::class is just a compile time transformation. It will give you the fully >qualified name of *something* as a string literal. The only exception to >this is when using ::class on objects, as this is a runtime transformation, >and when using with keyword static. > >When ::class is used with a class name, it will give you the name of that >class as a string. When used with a name of a function, it will give you >the name of that function as a string. When used with a string, it will >give you that string as a string. >See this example https://3v4l.org/EKnEd > >The fact that this gives you a callable is just coincidental with all >strings being callable in PHP. The reason why it works right now is >because a string can represent a name of a class, interface, trait or >function. >If we were to replace the transformation with something else, like it is >proposed here, we would have to ensure that it is as versatile as a plain >string. Otherwise we would be losing functionality. In my opinion, this is extremely unintuitive and surprising. I would not have expected this to work, and would consider this more of an unintended side effect rather than an actual feature of ::class. In my opinion, this is an argument for ::class producing a ClassName type, and for migrating such code that misuses it for functions to the first-class callable syntax (ie. strlen(...)). It might be even possible to issue a deprecation warning whenever a ClassName is coerced to a callable - I am not sure how feasible it would be to implement this, however. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
On 26 June 2021 02:39:52 CEST, Go Kudo wrote: >Hello Internals. > >RFC has been reorganized for finalization. > >https://wiki.php.net/rfc/rng_extension > >The changes from the previous version are as follows: > >- Changed again to a class-based approach. The argument can be omitted, in >which case an instance of XorShift128Plus will be created automatically. >- Future scope was specified in the RFC and the functionality was separated >as a Random extension. >- Changed to separate it as a Random extension and use the appropriate >namespace. >- In order to extend the versatility of the final class, Random, a >RandomInterface has been added, similar in approach to the >DateTimeInterface. > >I've done a tidy implementation to make this final, but I'm currently >suffering from error detection by Valgrind for unknown reasons. > >Implementation is here: https://github.com/php/php-src/pull/7079 > >This can be reproduced with the following code. > >```sh ># Success >$ valgrind ./sapi/cli/php -r '$random = new Random(); $random->nextInt();' >==95522== Memcheck, a memory error detector >==95522== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >==95522== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info >==95522== Command: ./sapi/cli/php -r $random\ =\ new\ Random();\ >$random-\>nextInt(); >==95522== >==95522== >==95522== HEAP SUMMARY: >==95522== in use at exit: 1,286 bytes in 32 blocks >==95522== total heap usage: 28,445 allocs, 28,413 frees, 4,333,047 bytes >allocated >==95522== >==95522== LEAK SUMMARY: >==95522==definitely lost: 0 bytes in 0 blocks >==95522==indirectly lost: 0 bytes in 0 blocks >==95522== possibly lost: 0 bytes in 0 blocks >==95522==still reachable: 1,286 bytes in 32 blocks >==95522== suppressed: 0 bytes in 0 blocks >==95522== Rerun with --leak-check=full to see details of leaked memory >==95522== >==95522== For counts of detected and suppressed errors, rerun with: -v >==95522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ># Fail >$ valgrind ./sapi/cli/php -r '$random = new Random(); $random->nextInt() >=== $random->nextInt();' >==95395== Memcheck, a memory error detector >==95395== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >==95395== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info >==95395== Command: ./sapi/cli/php -r $random\ =\ new\ Random();\ >$random-\>nextInt()\ ===\ $random-\>nextInt(); >==95395== >==95395== Conditional jump or move depends on uninitialised value(s) >==95395==at 0x966925: ZEND_IS_IDENTICAL_SPEC_VAR_VAR_HANDLER >(zend_vm_execute.h:27024) >==95395==by 0x99AC27: execute_ex (zend_vm_execute.h:57236) >==95395==by 0x99C902: zend_execute (zend_vm_execute.h:59026) >==95395==by 0x8DB6B4: zend_eval_stringl (zend_execute_API.c:1191) >==95395==by 0x8DB861: zend_eval_stringl_ex (zend_execute_API.c:1233) >==95395==by 0x8DB8D6: zend_eval_string_ex (zend_execute_API.c:1243) >==95395==by 0xA4DAE4: do_cli (php_cli.c:995) >==95395==by 0xA4E8E2: main (php_cli.c:1366) >==95395== >==95395== >==95395== HEAP SUMMARY: >==95395== in use at exit: 1,286 bytes in 32 blocks >==95395== total heap usage: 28,445 allocs, 28,413 frees, 4,333,070 bytes >allocated >==95395== >==95395== LEAK SUMMARY: >==95395==definitely lost: 0 bytes in 0 blocks >==95395==indirectly lost: 0 bytes in 0 blocks >==95395== possibly lost: 0 bytes in 0 blocks >==95395==still reachable: 1,286 bytes in 32 blocks >==95395== suppressed: 0 bytes in 0 blocks >==95395== Rerun with --leak-check=full to see details of leaked memory >==95395== >==95395== For counts of detected and suppressed errors, rerun with: -v >==95395== Use --track-origins=yes to see where uninitialised values come >from >==95395== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) >``` > >However, the detection is internal to the Zend VM and the cause has not >been identified. From the code, it looks like memory management is being >done properly. > >I have a somewhat tricky way of allocating memory to make the process >common, do I need to give some hints to Valgrind? > >If you know, I would appreciate your advice on this issue. > >Regards, >Go Kudo >Hello Internals. > >RFC has been reorganized for finalization. > >https://wiki.php.net/rfc/rng_extension I think this is a good reorganization. I would like to point out that this does not quite follow the Namespace Policy (https://wiki.php.net/rfc/namespaces_in_bundled_extensions): Notably it says: > All symbols defined in the extension should be part of the extension's > top-level > namespace or a sub-namespace. This means that the Random class and RandomInterface interface should be Random\Random and Random\RandomInterface respectively. The symbols in the Random\NumberGenerator sub-namespace are okay, as per the policy. Note, however, that the policy says "should", and if there is a good argument made, the guidelines mu
Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
>- `is_trusted()` - suggested by Moritz and separately by Mike, was the >second option in the original vote, and was based on the idea that what is >returned can be 'trusted' to be free from external code. Another idea - `is_internal()`, since it is not external code, and internal would be the opposite of external. Not quite sure how helpful/realistic this one is, but I wanted to bring it up either way. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)
>I would prefer an improved syntax for creation of anonymous objects. This >is something which I have been annoyed with, myself.I'd like to see a >simple way of creating anonymous objects with typed properties. Another advantage arrays currently have over anonymous objects is destructuring - if this was (somehow?) also made possible with objects, this would be the best of both worlds. (Returning multiple named values from a function is also mentioned in the use-cases of the RFC.) I know this works: ``` [ "foo" => $foo, "baz" => $baz ] = (array) $object; ``` (Alternatively also using get_object_vars() instead of casting.) But we both have to convert to an intermediate array again, and lose the type information of the object (eg. for static analysis), so this could also be made more ergonomic if we want to go down the anonymous object route. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Policy for procedural style in new additions
Hi internals, After the RFC to add IntlDatePatternGenerator () was accepted, it was brought up that the duplication of procedural and OO style was not necessarily/useful anymore. This already has some (old) precedent - in 2012, UConverter was added to ext/intl (https://wiki.php.net/rfc/uconverter) and in 2014 IntlChar (https://wiki.php.net/rfc/intl.char) - both of which only provide a class, but not the procedural API. This was also shortly discussed on the mailing list for IntlChar: https://externals.io/message/79146#79167 after which the procedural API was dropped without much ado. When I wrote the IntlDatePatternGenerator RFC, I was not aware that the procedural API was viewed as deprecated, nor that there had been additions to ext/intl that were purely OO. In the thread after its vote, it was also suggested that we add a policy that forbids new additions from adding duplicated APIs, and that OO style should be preferred if possible. I am not sure if I am the best person to write such an RFC, but I wanted to bring this to its own thread and provide the context I have dug up so far. The duplication of the OO and procedural API dates back to the addition of the intl extension to core. There is some discussion about it in this thread from 2008: https://externals.io/message/36775 (ignore the unrelated discussion about PHP6) The main argument at this point was that OO in PHP is a new thing, and that while the OO API is objectively better, the procedural API should also be there to lessen the learning curve for existing PHP users that are not yet familiar with OOP. I would argue that 13 years later, this argument no longer holds - anyone who has used PHP at some point since then most likely has encountered classes. One open question that still remains is what we do with the already existing procedural API. Should it be deprecated? Should it only be soft-deprecated, in that we mention in the documentation that the OO style is preferred, but that the procedural API is not planned to be removed? Should we just leave the procedural API as-is and live with the fact that some classes have procedural counterparts and some don't? I would personally lean towards (at least soft-) deprecation just for consistency, but I would like to hear what you would have to say. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
>Right, for the purposes of this RFC, it's okay to just drop them if there >are no objections. A general policy RFC may still be useful for future >reference. In that case, I will just go ahead and remove the procedural style from my implementation (unless someone speaks up and objects). I will move the general discussion to a new thread. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
>Agreed with Nikita. There's no compelling reason to add double-API style >anymore. It may take a second RFC to modify this one to remove those, >technically, but I'd vote for it. Should this new RFC then only apply to IntlDatePatternGenerator, or should it also clarify that future additions to the intl extension (or to extensions in general?) should not add both styles and prefer OO style if possible? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
>It's ... checks calendar ... the year 2021. Do we *really* need to add a >procedural mirror APIs, especially with such auspicious function names as >datepatterngenerator_get_best_pattern? > >I believe the procedural APIs are considered legacy APIs, and we are >intentionally not adding them for new functionality. For example, the most >recent intl addition (IntlChar) does not come with procedural APIs. I wasn't aware that there was a precedent with IntlChar - the documentation seems to frame this duplication as a feature rather than a historical artifact. (The wording "OO style vs procedural style" does not imply any endorsement of one style over the other to me.) However, i am open to only including the OO API if there is consensus - although I feel like this should maybe belong in a separate RFC that clarifies that future additions should prefer the OO style, and that the OO style is the "preferred" one. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
Hi Internals, I am pleased to announce that this RFC has been accepted unanimously. I have closed the vote. Regards, Mel - Original Message - From: "Mel Dafert" To: "internals" Sent: Friday, May 14, 2021 5:56:23 PM Subject: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator Hi Internals, I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator. I will close it on 2021-05-28. For previous discussion see https://externals.io/message/113831 and https://externals.io/message/114124. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Add IntlDatePatternGenerator
Hi Internals, I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator. I will close it on 2021-05-28. For previous discussion see https://externals.io/message/113831 and https://externals.io/message/114124. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add IntlDateTimePatternGenerator
I am planning to open the vote on this tomorrow, if there aren't any objections. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Could we drop the bottom-posting rule?
>> This plaintext reply sent via Gmail web client. I don't know what Mel is >> talking about either. >> >> >Gmail's web client is what I normally use, and have never had an issue with >it. Sorry for being unclear - I meant the Gmail android app. If the app does have an option for plaintext emails, I am not able to find it. If it does, that might also be useful to document somewhere, so people like me can actually use it :) Even then, I also don't think it offers an option to bottom-post by default - which K-9 and Thunderbird do. (No idea about the Gmail web client - I don't use it regularly.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Could we drop the bottom-posting rule?
On 10 May 2021 23:57:51 CEST, Christian Schneider wrote: >No. >Outlook is not modern. While I agree with this (and I also agree with keeping bottom-posting), I feel like we could make this easier for new contributors by giving some examples of which clients to use and how to configure them. What clients are people using that make this convenient? On desktop, I assume Thunderbird can do this, and my web client (zimbra) also can. On mobile, I've settled with the beta version of K-9 - I don't know of any other client that can do this. (Gmail certainly can't, it can't even send non-HTML mails, and even with K-9 I have to remember doing it.) And please don't say that mobile clients don't matter - if we want to make it easy for new people to join, we should also make sure we support using mobile. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add IntlDateTimePatternGenerator
>For both points, I'd say "consistency wins by default." So if the other >classes in that package already skip "Time" and use ::create() instead of a >constructor, you should do the same as well unless there's a very good reason >not to. I have updated the RFC to use switch to the naming without "Time", and added some notes about the naming options. (On a side note, I realized that HHVM/Hack also implements it without the "Time" part: https://docs.hhvm.com/hack/reference/class/IntlDatePatternGenerator/ ) I have also removed the open question about the `::create()` method, since the current form is consistent with `IntlDateFormatter`, which is what we want. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add IntlDateTimePatternGenerator
> For both points, I'd say "consistency wins by default." So if the other > classes in that package already skip "Time" and > use ::create() instead of a constructor, you should do the same as well > unless there's a very good reason not to. The problem with ::create is that in the intl extension itself there are already two different ways used (`IntlDateFormatter` exposes both, `IntlCalendar::__construct` is private) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Add IntlDateTimePatternGenerator
Hi Internals,
I would like to propose an RFC
https://wiki.php.net/rfc/intldatetimepatterngenerator to add
IntlDateTimePatternGenerator
which exposes ICU's ability to flexibly create localized date/time formatting
patterns from a skeleton.
Previous discussion: https://externals.io/message/113831
Implementation: https://github.com/php/php-src/pull/6771
Proposed signature:
```
class IntlDateTimePatternGenerator
{
public function __construct(?string $locale = null) {}
public static function create(?string $locale = null):
?IntlDateTimePatternGenerator {}
public function getBestPattern(string $skeleton): string|false {}
}
```
There is an open question about what this should be named
`IntlDatePatternGenerator` instead, both for brevity and to keep consistency
with `IntlDateFormatter`. (Note that the underlying ICU classes are called
`DateTimePatternGenerator` and `DateFormatter`, respectively.)
I am open to switching to the shorter form.
Another open question is the signature, as currently both `__construct` and
`create` are exposed (like `IntlDateFormatter`).
Other classes inside the intl extension (like `IntlCalendar`) only provide a
static `create` method, and leave the `__construct` method
private. Is there a preferred way, or are both equivalent?
Regards,
Mel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Request for RFC karma
Hello, I would like to request wiki karma to create an RFC for IntlDateTimePatternGenerator (see https://github.com/php/php-src/pull/6771). My wiki account name is deltragon. Thanks, Mel Dafert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
> Now that I see their implementation again, I'm wondering if > `IntlDateTimePatternGenerator` is the right name, or we should also use > `IntlDatePatternGenerator`, which is more in line with `IntlDateFormatter`. I was also wondering about that. I ended up going for `IntlDateTimePatternGenerator`, because ICU has that same inconsistency (`icu::DateFormat` and `icu::DateTimePatternGenerator`). I think the big argument here is discoverability - if someone is wondering about whether PHP exposes the feature from ICU, it might be harder to find it if we name it differently (and vice versa). PS: Sorry about the duplicate/badly formatted message - I am new to the concept of mailing lists. - Original Message - From: "Máté Kocsis" To: "Mel Dafert" Cc: "internals" Sent: Sunday, March 28, 2021 7:45:46 PM Subject: Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator Hi Mel, Thank you very much for working on this! I was bitten by lack of this functionality a few years ago, and I couldn't find any (good) alternative. Thus, I'm looking forward to having `IntlDateTimePatternGenerator` in ext/intl. I think it could be mentioned for those who don't open the bug report that HHVM implemented this class long ago: https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085 Now that I see their implementation again, I'm wondering if `IntlDateTimePatternGenerator` is the right name, or we should also use `IntlDatePatternGenerator`, which is more in line with ``IntlDateFormatter`. Regards: Máté Mel Dafert ezt írta (időpont: 2021. márc. 28., V, 16:54): -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
Now that I see their implementation again, I'm wondering if
`IntlDateTimePatternGenerator` is the right name, or we should also use
`IntlDatePatternGenerator`, which is more in line with `IntlDateFormatter`.
I was also wondering about that. I ended up going for
`IntlDateTimePatternGenerator`, because ICU has that same inconsistency
(`icu::DateFormat` and `icu::DateTimePatternGenerator`). I think the big
argument here is discoverability - if someone is wondering about whether PHP
exposes the feature from ICU, it might be harder to find it if we name it
differently (and vice versa).
From: "Máté Kocsis"
To: "Mel Dafert"
Cc: "internals"
Sent: Sunday, March 28, 2021 7:45:46 PM
Subject: Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
Hi Mel,
Thank you very much for working on this! I was bitten by lack of this
functionality a few years ago, and I couldn't find any (good) alternative.
Thus, I'm looking forward to having `IntlDateTimePatternGenerator` in ext/intl.
I think it could be mentioned for those who don't open the bug report that HHVM
implemented this class long ago: [
https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085
|
https://github.com/facebook/hhvm/commit/bc84daf7816e4cd268da59d535dcadfc6cf01085
]
Now that I see their implementation again, I'm wondering if
`IntlDateTimePatternGenerator` is the right name, or we should also use
`IntlDatePatternGenerator`, which is more in line with ``IntlDateFormatter`.
Regards:
Máté
Mel Dafert < [ mailto:m...@dafert.at | m...@dafert.at ] > ezt írta (időpont:
2021. márc. 28., V, 16:54):
BQ_BEGIN
Hello Internals,
I would like to propose an addition to the intl extension,
IntlDateTimePatternGenerator.
ICU exposes the DateTimePatternGenerator class that allows generating a
formatting pattern from a given "skeleton" for a given locale. (see [
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1DateTimePatternGenerator.html
|
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1DateTimePatternGenerator.html
] )
This allows more flexibility than the current $format argument of
IntlDateFormatter::format(), which takes either a few pre-defined constants or
a hard-coded format.
This functionality also has been requested in the past. (see [
https://bugs.php.net/bug.php?id=70377 | https://bugs.php.net/bug.php?id=70377 ]
)
For example, if an application requires a format that will always use the long
version of a year, but the short version of a month (eg. "MM/dd/" for
"en_US", or "dd.MM." for "de_DE"), one is out of luck.
IntlDateFormatter::SHORT will use the short year for "de_DE" ("dd.MM.YY"), and
IntlDateFormatter::MEDIUM will use the long version of a month for "en_US"
("MMM dd, ").
With IntlDateTimePatternGenerator::getBestPattern(), a skeleton can be provided
to generate the appropriate pattern for a given locale.
In the use-case given above, the skeleton "MMdd" will generate the desired
patterns for each locale, which can then be passed to
IntlDateFormatter::format().
Proposed Signature:
```
class IntlDateTimePatternGenerator
{
public function __construct(?string $locale = null) {}
public static function create(?string $locale = null):
?IntlDateTimePatternGenerator {}
public function getBestPattern(string $skeleton): string|false {}
}
```
Example use-case:
```
$date = new \DateTime();
$skeleton = "MMdd";
$dtpg = new \IntlDateTimePatternGenerator(); // uses default locale if not
specified
$format = $dtpg->getBestPattern($skeleton);
echo \IntlDateFormatter::formatObject($date, $format); // outputs "28.03.2020"
for "de_DE" locale
```
The proposed implementation can be found here: [
https://github.com/php/php-src/pull/6771 |
https://github.com/php/php-src/pull/6771 ]
I assume that this will require an RFC, in which case I request the karma to
create one. My wiki account is deltragon.
Regards,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [ https://www.php.net/unsub.php |
https://www.php.net/unsub.php ]
BQ_END
[PHP-DEV] Proposal: add IntlDateTimePatternGenerator
Hello Internals,
I would like to propose an addition to the intl extension,
IntlDateTimePatternGenerator.
ICU exposes the DateTimePatternGenerator class that allows generating a
formatting pattern from a given "skeleton" for a given locale. (see
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1DateTimePatternGenerator.html)
This allows more flexibility than the current $format argument of
IntlDateFormatter::format(), which takes either a few pre-defined constants or
a hard-coded format.
This functionality also has been requested in the past. (see
https://bugs.php.net/bug.php?id=70377)
For example, if an application requires a format that will always use the long
version of a year, but the short version of a month (eg. "MM/dd/" for
"en_US", or "dd.MM." for "de_DE"), one is out of luck.
IntlDateFormatter::SHORT will use the short year for "de_DE" ("dd.MM.YY"), and
IntlDateFormatter::MEDIUM will use the long version of a month for "en_US"
("MMM dd, ").
With IntlDateTimePatternGenerator::getBestPattern(), a skeleton can be provided
to generate the appropriate pattern for a given locale.
In the use-case given above, the skeleton "MMdd" will generate the desired
patterns for each locale, which can then be passed to
IntlDateFormatter::format().
Proposed Signature:
```
class IntlDateTimePatternGenerator
{
public function __construct(?string $locale = null) {}
public static function create(?string $locale = null):
?IntlDateTimePatternGenerator {}
public function getBestPattern(string $skeleton): string|false {}
}
```
Example use-case:
```
$date = new \DateTime();
$skeleton = "MMdd";
$dtpg = new \IntlDateTimePatternGenerator(); // uses default locale if not
specified
$format = $dtpg->getBestPattern($skeleton);
echo \IntlDateFormatter::formatObject($date, $format); // outputs "28.03.2020"
for "de_DE" locale
```
The proposed implementation can be found here:
https://github.com/php/php-src/pull/6771
I assume that this will require an RFC, in which case I request the karma to
create one. My wiki account is deltragon.
Regards,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
