[PHP-DEV] Multibyte for ucfirst function
Hi, Internals
We got feature request for "Multibyte for ucfirst function".
https://github.com/php/php-src/issues/13075
I think make sense for implement this function, but I don't know well
about not-latin language.
I have a question.
gnutix san pick up sample to below:
https://stackoverflow.com/questions/2517947/ucfirst-function-for-multibyte-character-encodings/58915632#58915632
```
function mb_ucfirst(string $str, ?string $encoding = null): string
{
return mb_strtoupper(mb_substr($str, 0, 1, $encoding), $encoding)
. mb_substr($str, 1, null, $encoding);
}
```
mb_strtoupper supports not-latin language, Therefore, that means
effect ucfirst not-latin language.
Manual of mb_strtoupper is shows example #2 not-latin language.
https://www.php.net/manual/en/function.mb-strtoupper.php#refsect1-function.mb-strtoupper-examples
What do we think? Feel free to comment.
Cheers for new year.
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] clarify the destructuring list() concept
Thank you for your reply. Forgive me for a few mistakes. I'm new to Gmail... Is this line "top-post" ? Le sam. 6 janv. 2024 à 00:48, Larry Garfield a écrit : > What you can do, as Rowan noted, is this: > > https://3v4l.org/cEmcC > > I understood your code. It is interesting when you do not know the order of the keys. https://3v4l.org/O29NL I would have preferred to be able to write: https://3v4l.org/o5jkH In the same way I do it here: https://3v4l.org/I4V3W I don't see any concrete case where using a variable as a key can be useful https://3v4l.org/WR54k For me it was implemented like this, because it's easier. In reality, I'm not asking "how" it actually works, but how it should work.
Re: Fwd: [PHP-DEV] clarify the destructuring list() concept
On Fri, Jan 5, 2024, at 5:16 PM, Mönôme Epson wrote: > -- Forwarded message - > I try to follow the procedure of: https://wiki.php.net/rfc/howto > > It seems to me that list() is not clearly specified. > I wanted to know your opinions on this. > > > For example : > $key = "a"; > $value = 1; > $array = [$key => $value]; > > [$key => $value] = $array; > > We all agree that now $key = 'a' and $value = 1 > > And I wonder why > What happens in this case : > > [$key => $value] = ['b'=>2]; > > $key = 'b' and $value = 2 or all is null ? Please don't top-post. As for what that does: https://3v4l.org/5ubJU That's because the right-side can have many keys with their own values, but the left side... doesn't really do that. The left side only assigns values, not keys. I'm not sure how it would be useful to decompose like you're describing, since it would only really make sense with a single array item on the left, which is not a common or useful case. What you can do, as Rowan noted, is this: https://3v4l.org/cEmcC That pulls items out of the array by key, into named variables. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Fwd: [PHP-DEV] clarify the destructuring list() concept
-- Forwarded message - De : Mönôme Epson Date: sam. 6 janv. 2024 à 00:15 Subject: Re: [PHP-DEV] clarify the destructuring list() concept To: Rowan Tommins Le ven. 5 janv. 2024 à 23:31, Rowan Tommins a écrit : > > I'm not sure what your question is I try to follow the procedure of: https://wiki.php.net/rfc/howto It seems to me that list() is not clearly specified. I wanted to know your opinions on this. For example : $key = "a"; $value = 1; $array = [$key => $value]; [$key => $value] = $array; We all agree that now $key = 'a' and $value = 1 And I wonder why What happens in this case : [$key => $value] = ['b'=>2]; $key = 'b' and $value = 2 or all is null ? Le ven. 5 janv. 2024 à 23:31, Rowan Tommins a écrit : > The name for this if you want to find more information is "array > destructuring". list() supports destructuring assignment for arrays. Do you have an opinion on object destructuring ? *Do you think seeing list() as the reciprocal of a function call is interesting ?* Otherwise, how to use a default value, type hinting, nullable/optional variable... It's not interesting ? There are many things that could be done with but don't work. For example : $array = [1, 2, 3]; [...$values] = [...$array]; My question is: I see list() as the reciprocal of an array(). Do you think it would be interesting for everyone if I proposed my vision?
Re: [PHP-DEV] clarify the destructuring list() concept
On 5 January 2024 20:44:00 GMT, "Mönôme Epson" wrote:
>Hello internals,
>
>> The purpose of list() is to assign a list of variables.
>
>What should be the underlying concept behind the list() language construct?
>
>I propose that list() is the reciprocal of array().
>That is, if array() is a function call, then list() is the signature of a
>function.
>
>Do you agree ?
>
>Regards, Alexandre
>
>PS: For historical reason, i propose to allow to syntaxe :
>list(name: $name) = ['name'=>$name];// maybe discussed
>list('name'=> $name) = ['name'=>$name];
I'm not sure what your question is, but the second option, with => as in all
PHP contexts, already works: https://3v4l.org/dqgal
Note that neither array() nor list() are functions, and both can be spelled []
as in
['name'=> $name2] = ['name'=>$name1];
https://3v4l.org/Uu5e4
The name for this if you want to find more information is "array destructuring".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] clarify the destructuring list() concept
Hello internals,
> The purpose of list() is to assign a list of variables.
What should be the underlying concept behind the list() language construct?
I propose that list() is the reciprocal of array().
That is, if array() is a function call, then list() is the signature of a
function.
Do you agree ?
Regards, Alexandre
PS: For historical reason, i propose to allow to syntaxe :
list(name: $name) = ['name'=>$name];// maybe discussed
list('name'=> $name) = ['name'=>$name];
[PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository
Hi, I have just opened the voting on the "Policy Repository" RFC. It will run until January 22nd, 2024 at 08:00 UTC: https://wiki.php.net/rfc/policy-repository#voting_choices cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Fri, Jan 5, 2024 at 9:40 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> There are indeed dozens of libraries already working with PSR nicely but
> IMHO
> the API should provide all the necessary information in a way that allows
> the construction of such objects,
> but suggesting PSR with request/response objects will limit the
> capabilities of worker mode API
> to handle pure HTTP protocol only.
>
> What I'd like to say is that I believe for the initial proposal of any
> eventual worker mode API
> with the PSR with request/response objects should not be considered at all.
>
> Cheers
>
I think it's been mentioned quite a few times that it doesn't matter what
gets passed to the callable function that hands over control to userland,
as long as it's more functional-style and not superglobals. I also think
that there's merit in both sides of the conversation between PSR-7 vs
associative arrays, but I find it more important to get one of them, any of
them and not halt for one or the other. PSR would make it HTTP-only, yes,
but that largely benefits the PHP ecosystem to an extent order of magnitude
larger than any non-HTTP format. On the other hand, being a dynamically
typed language, nothing holds us from having a more simple/generic
`function handler(mixed $event)` format which can also be used to process
HTTP and non-HTTP events.
I do prefer the more generic one as I would be interested in seeing what
PHP would become with the capability of processing non-HTTP protocols made
easier. That being said, I find it important to consider the quality of
such an API for its users. It would end up forcing users to do the
following:
```
function handler(mixed $event) {
if (isset($event['_REQUEST'])) {
// We are on HTTP Protocol
}
if (isset($event['...'])) {
// This is a Websocket
}
}
```
If the original proposal is correct and/or my little understanding of this
thread is somewhat in the right direction, it means that the introduction
of a PHP function that asks its engine for the next event to process isn't
a huge amount of work on PHP Internals. If that's true, I would ask that we
consider making something more flexible / forgiving of errors / adjustable
and evolution-friendly. Instead of striving so much for coming up with one
perfect API that shall be the one true API for PHP for the next decade, we
can instead consider the possibility of having multiple small APIs that can
harmonically coexist. Example:
Classic:
```
$classicHttpHandler = function (array $get, array $post, array $request,
array $server, array $cookies): string|Stringable {
// process incoming request in a somewhat backward-compatible friendly
way
return 'http response'; // Return the response similarly to how we used
to `echo` it to the server.
}
worker_http_classic($classicHttpHandler);
```
PSR-7:
```
$httpMiddlewareHandler = function (\Psr\Http\Message\RequestInterface
$request): \Psr\Http\Message\ResponseInterface {
// Process Request
}
worker_http_psr7($httpMiddlewareHandler);
```
HTTP Raw
```
$httpHandler = function (\Psr\Http\Message\StreamInterface $raw):
\Psr\Http\Message\ResponseInterface {
// Process Request
}
worker_http_raw($httpHandler);
```
STDIN
```
$stdinHandler = function (SomeStdinCompatibleType $stdin):
SomeStdoutCompatibleType {
}
worker_stdin($stdinHandler);
```
Websocket
```
$websocketHandler = function (string $event, mixed $data): ??? {
// Process websocket incoming event
}
worker_websocket_event($httpHandler);
```
These APIs don't need to be ready on day one. They don't even need to be
ready at all, actually. Each would end up being its own RFC. What makes the
system a bit more. flexible is the api naming which follows the pattern PHP
Engine Namespace (worker), Purpose Namespace (_http, _websocket, etc) and
Variation Namespace (_classic, _psr7, _raw).
For me personally one awesome last step would make this a PHP Class instead
of procedural functions. That would be even better because we could use the
Class namespace itself to version it and provide future changes without
breaking what's been introduced already.
--
Marco Deleu
Re: [PHP-DEV] [RFC] [Vote] Resource to object conversion
Hi Máté, I have one question. If the primary stream resources get the is_resource hack, what hampers the changes from landing in a minor version? I'd assume that the migration would be mostly seamless. Is it the get_resource_type checks? Is it because is_resource also checks whether the resource is closed? Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On 5 January 2024 12:18:51 GMT, Robert Landers wrote: >This is easy to handle from C. If the callback takes an argument, >don't fill in the super-globals. Again, that's compatible only in a narrow sense: it provides both APIs on any run-time which can do so safely. You still have an incompatible upgrade to make though: if you write code today for FrankenPHP, and directly use the super-global arrays it populates, you cannot take that code tomorrow and use it in Swoole, which does not provide those super-globals. If you write code today which uses callback parameters, you can take that code and use it unmodified with any system which provides those parameters - including async implementations. All that's missing for that to happen right now is a standard format for those parameters. > It allows legacy apps to be slowly >"upgraded" while allowing newer apps to take full advantage of a SAPI. It's actually quite easy to add most of the backwards compatibility needed for legacy apps in userland, by populating the superglobals, and running an output buffer to capture echo etc into the response. > However, if we go into the design with the >concurrent server story in mind, I think we can create something much >better than what is available from FrankenPHP. Precisely. That's why I used the phrase "forwards compatibility" - I'm not saying php-src needs to support all of this right now, just that *the API design* should have an eye on the future, not just the past. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
pt., 5 sty 2024 o 13:19 Robert Landers napisał(a): > On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins > wrote: > > > > Globals is how this works (atm) > > > > It's how it works for native SAPIs. It's not, as far as I know, how any > worker system other than FrankenPHP has implemented its API. Every other > implementation I've seen, whether async or not, passes in some form of > request data to the callback, with the exception of RoadRunner, which gives > the data as a return value from a "get next request" function. > > Nearly every library in existence knows how to use these globals > (including 30 years old legacy code). There are also the unwieldy PSR > request/response containers for which there are dozens (if not > hundreds) of implementations. It would be fantastic if there were > already an extension-based implementation that could be adopted into > php-src; though I feel like that is a separate conversation. > There are indeed dozens of libraries already working with PSR nicely but IMHO the API should provide all the necessary information in a way that allows the construction of such objects, but suggesting PSR with request/response objects will limit the capabilities of worker mode API to handle pure HTTP protocol only. What I'd like to say is that I believe for the initial proposal of any eventual worker mode API with the PSR with request/response objects should not be considered at all. Cheers
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Fri, Jan 5, 2024 at 11:59 AM Rowan Tommins wrote: > > On 5 January 2024 09:02:05 GMT, Robert Landers > wrote: > > I don't think they are fundamentally incompatible. If we look at > >FrankenPHP's implementation, you pass a callback that gets called when > >there is a request. > > No, you pass a callback which is called exactly once, for the next request. > You have to implement your own loop if you want to handle multiple requests, > which obviously isn't how it would work with an async event loop. > > That was one of my suggested changes: move the loop into C, so that the API > was "callback called for each request". This actually *adds* flexibility on > the server end, to decide how often to call that callback, do so > asynchronously, etc. I think the goal here is to provide the basic building block: a function that takes a callable that, when called, blocks the script. Even when you have an event loop, there is some point when you call something and enter an infinite loop (the event loop), and no more of that file will be called ($app->start() or whatever). This is _that function_ for all intents and purposes. You can implement your own event-loop using do/while (such as in FrankenPHP), or a SAPI can call it in a loop for you. The bedrock is in core PHP, providing a standardized way of setting this up ... obviously, there are also SAPIs out there doing their own thing, and there always will be. > > Globals is how this works (atm) > > It's how it works for native SAPIs. It's not, as far as I know, how any > worker system other than FrankenPHP has implemented its API. Every other > implementation I've seen, whether async or not, passes in some form of > request data to the callback, with the exception of RoadRunner, which gives > the data as a return value from a "get next request" function. Nearly every library in existence knows how to use these globals (including 30 years old legacy code). There are also the unwieldy PSR request/response containers for which there are dozens (if not hundreds) of implementations. It would be fantastic if there were already an extension-based implementation that could be adopted into php-src; though I feel like that is a separate conversation. > So, the second suggested change is to standardise on the most common pattern > of passing parameters to a callback, rather than the unusual one of > populating and clearing superglobals. As a bonus, this pattern works with > both non-async and async workers. > > > > changing the signature of the callback is generally backwards compatible > > This is true in the narrow sense that it won't cause any fatal errors. But if > you write your application assuming that it will run in an environment where > globals are populated for you, it will not run in an environment which no > longer populates those globals. This is easy to handle from C. If the callback takes an argument, don't fill in the super-globals. It allows legacy apps to be slowly "upgraded" while allowing newer apps to take full advantage of a SAPI. That's how I would implement it, anyway. There is also something to be said to go "all the way" and just abandoning legacy apps, but that doesn't feel like something PHP would do. > >Changing the underlying implementation in php-src when there are > >native fibers/event loops probably won't even change anything (since > >that was exactly how they were designed). > > Sounds great! So we don't need to wait to put that implementation in place > then. > > > > >But holding up the entire conversation ... > > There is no reason whatsoever to hold anything up. The suggestion is not > "don't implement any worker API until we have an async implementation", it's > "a worker API sounds great, let's implement one that looks like this". > > Yes, it might take slightly longer to define some new array structures, but > we're talking about a few hours work to give us a much more flexible system, > not weeks of complex engineering. > > If the proposal is "copy some code from FrankenPHP into php-src, which nobody > else will want to use", it's pointless; if it's "standardise an API with some > enabling code", then *of course* we want to spend a bit of time designing > that API. That's fair. I was taking this push-back from you and others as, "No, we don't want this unless we can have all these other things," so thank you for clarifying that. I can largely agree -- I use amphp + fibers extensively in another project, so seeing more love for concurrent servers would be nice. Maybe I saw it that way because I have a fairly deep understanding of the shortcomings with fibers/async-php and see the amount of work required to support what you are proposing. However, if we go into the design with the concurrent server story in mind, I think we can create something much better than what is available from FrankenPHP. > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List >
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On 5 January 2024 09:02:05 GMT, Robert Landers wrote: > I don't think they are fundamentally incompatible. If we look at >FrankenPHP's implementation, you pass a callback that gets called when >there is a request. No, you pass a callback which is called exactly once, for the next request. You have to implement your own loop if you want to handle multiple requests, which obviously isn't how it would work with an async event loop. That was one of my suggested changes: move the loop into C, so that the API was "callback called for each request". This actually *adds* flexibility on the server end, to decide how often to call that callback, do so asynchronously, etc. > Globals is how this works (atm) It's how it works for native SAPIs. It's not, as far as I know, how any worker system other than FrankenPHP has implemented its API. Every other implementation I've seen, whether async or not, passes in some form of request data to the callback, with the exception of RoadRunner, which gives the data as a return value from a "get next request" function. So, the second suggested change is to standardise on the most common pattern of passing parameters to a callback, rather than the unusual one of populating and clearing superglobals. As a bonus, this pattern works with both non-async and async workers. > changing the signature of the callback is generally backwards compatible This is true in the narrow sense that it won't cause any fatal errors. But if you write your application assuming that it will run in an environment where globals are populated for you, it will not run in an environment which no longer populates those globals. >Changing the underlying implementation in php-src when there are >native fibers/event loops probably won't even change anything (since >that was exactly how they were designed). Sounds great! So we don't need to wait to put that implementation in place then. >But holding up the entire conversation ... There is no reason whatsoever to hold anything up. The suggestion is not "don't implement any worker API until we have an async implementation", it's "a worker API sounds great, let's implement one that looks like this". Yes, it might take slightly longer to define some new array structures, but we're talking about a few hours work to give us a much more flexible system, not weeks of complex engineering. If the proposal is "copy some code from FrankenPHP into php-src, which nobody else will want to use", it's pointless; if it's "standardise an API with some enabling code", then *of course* we want to spend a bit of time designing that API. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
Hi, > But holding up the entire conversation because these things don't even > exist, BTW, I'm not asking to wait for the implementation of a native event loop before implementing a worker mode, I'm asking to design the worker mode API in a way that is compatible with an eventual native event loop (that I hope will eventually get merged into php, as the current status quo of blocking STL I/O is definitely not ideal for a programming language in 2024). Using superglobals for request information is already using a wrong approach in sight of native async, and while technically this is not completely incompatible with fibers, as superglobals can simply be copied immediately as soon a fiber is started, the same cannot be said for php://output and php://input streams, which cannot be copied in any way. I ask to completely avoid altering superglobals and other global state such as the php://input/output streams, and instead directly pass/return an array/object (it really does not matter to me if it's a PSR-7 RequestInterface or an array containing _GET, _POST, input, output keys, or anything else as long as superglobals and global state is not touched in any way). Backwards compatibility for code using superglobals is really a non-issue here, as worker mode in itself is already potentially NOT automatically backwards-compatible with legacy code, since applications running in worler mode have to deal with the fact that the global state is not reset at the end of each request. This in itself is not an issue as mentioned before, thanks to work inside of major PHP frameworks to better support worker mode, I.e. laravel octane, but since the beneficiaries of worker mode will mostly be modern frameworks and most legacy code will already require changes to better support it, using a new API with a standalone request object/array instead of superglobals is not a real issue. Regards, Daniil Gentili.
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Fri, Jan 5, 2024 at 8:47 AM Rowan Tommins wrote: > > On 5 January 2024 06:55:34 GMT, Robert Landers > wrote: > > >I already said this, but to reiterate: I, personally, hear what you > >are saying and largely agree with you; however, before we can really > >have any kind of discussion on concurrent servers, we HAVE to address > >the underlying issues that are missing from PHP. In PHP-src > > So, let's address them... > > > > there are no such things as request objects > > This is a non-issue. As has been discussed already, it's perfectly fine to > have an event-based system where the event details are an associative array, > rather than a rich object. > > > > > There are no such things as event loops. There are fibers, > > but absolutely no std-library i/o functions are using them > > This is what the bulk of Daniil's email is suggesting a way to improve. > > > >We have a long way to go before those will be real things that we can > >have a proper conversation about in the context of php-src. > > If we keep waiting to have the conversation, it will never happen. > > And if we start building brand new APIs like infrastructure for worker-mode > SAPIs, in ways that are fundamentally incompatible with async, we're just > making more work for ourselves when we do get there. I don't think they are fundamentally incompatible. If we look at FrankenPHP's implementation, you pass a callback that gets called when there is a request. This is the same as giving Swoole a callback to call when a request is received, though the underlying implementation might be very different. An event-loop doesn't matter here and what gets passed to the callback is what we are discussing here. The exact implementation (in php-src) matters, but only so far as what php-src is capable of. Globals is how this works (atm) and changing the signature of the callback is generally backwards compatible. For example, if we start with only globals (no parameters), adding parameters later once there are request objects/arrays/whatever, is fine. Calling a callback with parameters when the function actually doesn't accept any arguments, isn't even a notice (https://3v4l.org/URj9b). Changing the underlying implementation in php-src when there are native fibers/event loops probably won't even change anything (since that was exactly how they were designed). But holding up the entire conversation because these things don't even exist, seems like a pointless endeavor since they may not even pass the RFC point (IIRC, getting an event-loop in PHP was a large part of the reason fibers are the way they are because people were against an event-loop at that time). > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [Vote] Resource to object conversion
Hi Everyone, As mentioned a few days ago, I've just opened the vote about resource to object conversion. The vote will be open for 2 weeks. RFC link: https://wiki.php.net/rfc/resource_to_object_conversion Discussion thread: https://externals.io/message/121660 Regards, Máté
