Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
2024年3月5日(火) 5:52 Niels Dossche :
>
> Hi Yuya
>
> This sounds useful.
>
> I do have a question about the function signature:
> function grapheme_str_split(string $string, int $length = 1): array {}
>
> This always returns an array.
> However, looking at your PR it seems you return NULL on failure, but the
> return type in the signature isn't nullable.
> Also, from a quick look, it seems other functions return false instead of
> null on failure. So perhaps the return type should be array|false.
>
> What do you think? :)
>
> Kind regards
> Niels
>
> On 03/03/2024 00:21, youkidearitai wrote:
> > Hi, Internals
> >
> > I noticed PHP does not have grapheme cluster for str_split function.,
> > Until now, you had to use the PCRE function's \X.
> >
> > Therefore, I try create `grapheme_str_split` function.
> > https://github.com/php/php-src/pull/13580
> > It is possible to convert array per emoji and variation selectors using ICU.
> >
> > If it's fine, I'll create an RFC.
> >
> > Regards
> > Yuya
> >
Hi, Niels
Thank you for your comment.
Indeed, returns false is make sense.
Therefore, I changed to returns false when invalid UTF-8 strings.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
[PHP-DEV] PHP 8.2.17RC2 available for testing
PHP 8.2.17RC2 has just been released and can be downloaded from: https://downloads.php.net/~sergey/ or https://qa.php.net/ or use the git tag: php-8.2.17RC2 Windows binaries are available at: https://windows.php.net/qa/#php-8.2 Please test it carefully, and report any bugs to https://github.com/php/php-src/issues PHP 8.2.17 should be expected in 2 weeks, i.e. on March 14, 2024. Hash values and PGP signatures can be found below or at https://gist.github.com/saundefined/1963093b6742638ab78f8948dcf9c9bf Thank you, and happy testing! Regards, Pierrick Charron, Sergey Panteleev & Ben Ramsey php-8.2.17RC2.tar.bz2 SHA256 hash: ba7f5dfeca1c3ad29c0fb0d1880453a47e00d527dcda74118754d9d9b89c3e3b PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmXe2VIACgkQZZqXyc8q eVq3lg//bAL7NtUGFN9nnRs0WKx66c6DWofsYMe54JIflAG6IBiSnRw9Sr6C94M5 KGBvFud2TKduj9KuE3R++yBLJq0ZYWzgYjg6urqNzHAXDN3UN2jr7ryUWlfm+Hv7 tAFhd1DtLVYwRvgjfveVzy8uAXy765t842tZS7GaBOQNrqfPf1hg+J0TktROMsNf UaywUdezdx9tzStDRrcrdyD7Bcz99/TLVZ8TLQ5AFxclwILSMrhETAC4bp8xIEYF O/zp7u18P1uhmR4nMhDPGabenbaLJzyDAsiXG46evabVpdfmurTfWPQ1RN6XzpaD KQgRHmHEMGzoAfwcvczVjYofQRTVfp08xs1bdsx9YFkcu/qRbAXRKVyuGhdWPnzy Om352CxKwcZUHqKRBv5xIwkCCHFyUbY7AqVU+q2B02a9cpmbSSZEATaQCGkOoLq6 HOvvsfTTt+BKfRjTCGvjImnPEVO6HC6SdeAJM1HesaehgEBY2a81e4IT9SsxlAlY RLqj+hpTG/K7P57TLntGyp4yzIk+Mli7AREFCUNg6iu3gehrGP1Q+JKfzHD99sBB w8VVFJxP+osuWTLOsRmGWp/uv789VbHLhkt5TKyq/2e8INUL4s/Tx8ngtOfQ4mPY 8U+qcUW64+QkuNJ3m12+Kl03li0QxY8wJXJtSpokIyayvSqJMTg= =yrcq -END PGP SIGNATURE- php-8.2.17RC2.tar.gz SHA256 hash: fc878f53053b94b8b64f8e064bf424df1cfff1a9a24ff25fe68b85bbf12552f4 PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmXe2VYACgkQZZqXyc8q eVpXmw//XSvJIYqPRT1kaNDy+WKryGBB5JtFIMOsYYLVqAhMVf4+tLgSCefWglog lvkeY164RP6c8a9i0CskN3JDJ/7x3f/Pe5ayD8S4OkeI8UylsD49WLoBcaOctpug ZAreAyQCCtyeC9+vQKVrMXRTsO70q/rUyS/b7vmUotXt3zr+TnMsgoFrjcZ2nazF SMo/wknYPbvQ4ac0KtEp83Do60hoRfFhttKQ69z0ALwGWdSt2Jg7cz3d3+vJSrT+ +ZqbllCeVSAbXD7V396DEbTf6WJzcahwCkUcGOMNZ/mBCw3iZ8u+51Wbca3r+khf 0xkXqVwQb4Q0HCegloZ6ayQRiOHh+1OcdERH3n9M6EHxeTRhldqfkSWvnPgHrqV2 YsNpl1l3NQsRKX2htzYhvkcjuaYRecggY5ps6hI8MDxTj+Exh4p3c4uJzVonIROG 5JlSYlDXdnhsin0j2SMGe4UApnh4WBNyzhWdaaB/o+DPZ4gKpP8s2Cnl0SyYKklI rJ0OES4fBgMvniO0rr4flCLc1LIXckSPL0BhbG1DRlVzy3scBEThrqxYBmTvuhP9 RudHl5pUF30aBaK8mPCZUpfxNBowNfIByA+CcsOKWcnFOiXrtJIPAFfwLL1xQQj3 EGle3McTzjTT5thhqbxvXHbZAFxlS+L8cvNsDlbQ1EHSN0SLbrY= =h/UY -END PGP SIGNATURE- php-8.2.17RC2.tar.xz SHA256 hash: 308d19f36f11bed79092706eea4f3259ea977ce455213a67f106987ce0c64f6e PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEE5gkT5N8gmQfY4w2WZZqXyc8qeVoFAmXe2VcACgkQZZqXyc8q eVpWwxAAndkj5P2bQMhI00rSV2e3AflGKx9asFDHWqaJ91pZdqP7kXLs3VDhdTx4 AfePxPADKosNJwCuNsgwVDkQ3jx1LlFC4rvZiWQLXKrOqmfPgFYtQIhSR1xEEofS NSFwluOg8PFl3ZC+9mihuBBxghTSIG8WXiGHnpXXXmVbkTpcj2y99f+dWppHqAM6 +FHRQsFNW5ApV/7kAbgy5Zj+tC5T2ba807VtiGftJDUMPewa35r1CHnTZhjwQvWv 6ZVfI8jsW+7WQQ4S3O1j2KHEglHNtA1MLzO2CxfeaAiZZOSh0xrVlOPAc6oA+XNf 5NIzE5EpYpFIjkO2ei7TR6vjSKYC6sfkSFu/zInrcwX8IYOD6tVRG70xLUfzEK43 Mi4pU/4E2kKAUIEylPRGDzEWQJs2YSiUYiAYF4sVcGeWOrbpoY5H72JTyoZrAZCo e6hzuorU83bvBG4mAkCvXduZN0euV99F2dp7JsOOb/SspWhWX1CGpiqT0hnQ9McS Ary8/ioLfhy+kUp0ZDf6cFzBwhFdvyAtJ2F3S773q1aEg73YapEWQ41ikB4ciPto pXuvyDWpohs3zloOsg73KkgLAK9PEpy3rCUWd+qqYxrgOQze3veDzGQJO79VspS3 Qkrwn2Y97GDHcgTmEepVVoU7MQ5khVg3NM0KpFRY/Am9CsFGZTo= =3OP0 -END PGP SIGNATURE- signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] is this thing on?
Hey Folks. Am 05.03.24 um 00:11 schrieb dan...@daniil.it: The VSC part from github (hosting our code), can very easily be ported. Issues, discussions etc can not. With the ongoing enshittification of most of the Internet due to advertising and tracking, we'd be negligent not hosting and owning our own content (including our issue tracker, but that ship has sailed now). PHP actually recently moved from a self-hosted VCS to github due to a hack that compromised php's source code, moving back to a self-hosted instance seems like a downgrade. However, if that's being discussed, it can be done properly, i.e. with a self-hosted gitlab instance, which also provides issues, projects, CI, basically the full devops experience, that would be the perfect chance to also move the mailing list and php wiki to gitlab (which is how many FOSS projects work currently, I.e. wayland, xorg, mesa, pipewire, asahi use the gitlab.freedesktop.org gitlab instance, arch linux has its own gitlab instance (which is also used for RFCs)). Email has been around for half a century. Will things like Slack, Discord, and the like still be operational and allow access to our archives in another 25 years? I'm almost certain it won't be. No one is proposing to move the issue tracker to discord, slack or telegram: those are messengers, and should not be used as support forums for such a major language, mainly because they're non-indexable. Regards, Daniil Gentili If I have learned one thing in decades of software development and emergency management it is: Never change a process in an emergency Processes are there to help in emergencies. They provide stable ways to process information. And in any case, any decission taken in an emergency situation will be influenced by the wish to fastly overcome the emergency and not by the wish to optimize the process. Also discussions about whether a process is necessary or not or needs to be changed wastes resources that can help solve the problem. That said: It is fine to discuss whether the mailinglists are the best thing to foster communication about the development of PHP - when the mailinglist is working fine. When the mailinglist is broken (and it'S not that that happens every other week) the only discussion is either about the development of PHP or how one can help to fix the issue. Some things didn't go well. Some things did go well. We (meaning those that fixed and still fix the issues at hand) might come together for a retrospective once everything works fine again and see what can be improved to help avoid such a situation the next time. Once that is done and everything works fine I am looking forward to an RFC proposing better ways to communicate about all the aspects of developing PHP in a worldwide distributed community of volunteers. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] is this thing on?
> The VSC part from github (hosting our code), can very easily be ported. > Issues, discussions etc can not. > > With the ongoing enshittification of most of the Internet due to advertising > and tracking, we'd be negligent not hosting and owning our own content > (including our issue tracker, but that ship has sailed now). PHP actually recently moved from a self-hosted VCS to github due to a hack that compromised php's source code, moving back to a self-hosted instance seems like a downgrade. However, if that's being discussed, it can be done properly, i.e. with a self-hosted gitlab instance, which also provides issues, projects, CI, basically the full devops experience, that would be the perfect chance to also move the mailing list and php wiki to gitlab (which is how many FOSS projects work currently, I.e. wayland, xorg, mesa, pipewire, asahi use the gitlab.freedesktop.org gitlab instance, arch linux has its own gitlab instance (which is also used for RFCs)). > Email has been around for half a century. Will things like Slack, Discord, > and the like still be operational and allow access to our archives in another > 25 years? I'm almost certain it won't be. No one is proposing to move the issue tracker to discord, slack or telegram: those are messengers, and should not be used as support forums for such a major language, mainly because they're non-indexable. Regards, Daniil Gentili
Re: [PHP-DEV] is this thing on?
On 4 March 2024 22:26:37 GMT, dan...@daniil.it wrote: >> Has Microsoft made a commitment to support open source forever? I mean MS >> owns Github, what ensures that it will stay free? > >This is a silly argument, if that were the case, maybe the VCS should move >back to a self-hosted instance too? The VSC part from github (hosting our code), can very easily be ported. Issues, discussions etc can not. >Jokes aside, if Microsoft suddenly decides to throw away or to charge for >github, one of their biggest assets after Windows and OpenAI, PHP would have >bigger problems than RFCs being managed on the github issue tracker. With the ongoing enshittification of most of the Internet due to advertising and tracking, we'd be negligent not hosting and owning our own content (including our issue tracker, but that ship has sailed now). Email has been around for half a century. Will things like Slack, Discord, and the like still be operational and allow access to our archives in another 25 years? I'm almost certain it won't be. cheers Derick
Re: [PHP-DEV] is this thing on?
> Has Microsoft made a commitment to support open source forever? I mean MS > owns Github, what ensures that it will stay free? This is a silly argument, if that were the case, maybe the VCS should move back to a self-hosted instance too? Jokes aside, if Microsoft suddenly decides to throw away or to charge for github, one of their biggest assets after Windows and OpenAI, PHP would have bigger problems than RFCs being managed on the github issue tracker. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
On 04.03.2024 20.20, dan...@daniil.it wrote: >> Mailing lists are fine and PHP is not the only project using them. The >> Linux kernel successfully uses them, the HAProxy project does as well >> and so does Debian. >> >> Best regards >> Tim Düsterhus > > Hi, Internals > > There are times when I explore archives (mbstring and character code > etc), so it's helpful to have something left in communication form. > Therefore a mailing list would be better for that. Modern programming languages like Rust and Go use exclusively github for internals discussion and RFCs, and all conversations are easily accessible, searchable and indexed by Google, with a much better UX than mailing lists. Just my two cents, I still believe using mailing lists and an invite-only wiki adds needless friction. Regards, Daniil Gentili. Has Microsoft made a commitment to support open source forever? I mean MS owns Github, what ensures that it will stay free? Regards Lars Nielsen
Re: [PHP-DEV] is this thing on?
>> Mailing lists are fine and PHP is not the only project using them. The >> Linux kernel successfully uses them, the HAProxy project does as well >> and so does Debian. >> >> Best regards >> Tim Düsterhus > > Hi, Internals > > There are times when I explore archives (mbstring and character code > etc), so it's helpful to have something left in communication form. > Therefore a mailing list would be better for that. Modern programming languages like Rust and Go use exclusively github for internals discussion and RFCs, and all conversations are easily accessible, searchable and indexed by Google, with a much better UX than mailing lists. Just my two cents, I still believe using mailing lists and an invite-only wiki adds needless friction. Regards, Daniil Gentili.
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
Hi Yuya
This sounds useful.
I do have a question about the function signature:
function grapheme_str_split(string $string, int $length = 1): array {}
This always returns an array.
However, looking at your PR it seems you return NULL on failure, but the return
type in the signature isn't nullable.
Also, from a quick look, it seems other functions return false instead of null
on failure. So perhaps the return type should be array|false.
What do you think? :)
Kind regards
Niels
On 03/03/2024 00:21, youkidearitai wrote:
> Hi, Internals
>
> I noticed PHP does not have grapheme cluster for str_split function.,
> Until now, you had to use the PCRE function's \X.
>
> Therefore, I try create `grapheme_str_split` function.
> https://github.com/php/php-src/pull/13580
> It is possible to convert array per emoji and variation selectors using ICU.
>
> If it's fine, I'll create an RFC.
>
> Regards
> Yuya
>
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Mon, Mar 4, 2024, at 3:45 PM, Robert Landers wrote:
> I would think that simply using return-to-set would be the simplest
> solution, if you need to run something after it's set, you can use the
> regular way of running code after a return:
>
> try {
> return $value + 100;
> } finally {
> // this runs after returning
> }
That would not work. Fun fact, the finally block runs *before* return. (This
is a common point of confusion.) So this would still not allow for statements
to run after the assignment itself (the return) happens.
--Larry Garfield
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
Hi Kamil On Mon, Mar 4, 2024 at 4:43 PM Kamil Tekiela wrote: > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. It would probably make sense to also list `session.trans_sid_tags` and `session.trans_sid_hosts` as deprecated. And mentioning that `output_add_rewrite_var()` is unaffected wouldn't harm either. -- Best regards, Bruce Weirdan mailto:weir...@gmail.com
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
On 03/03/2024 23:33, Kamil Tekiela wrote: > Hi Anton, > >> 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 was not aware that some frameworks do that. But I don't understand > how this works. IMHO if you disable the use of cookies, but you also > tell PHP to use only cookies it creates an impossible scenario. Isn't > that right? > > The way I understand it is that there are 2 ways of propagating > session ID: cookies and GET/POST. You can tell PHP to use both or > either one of them, but not neither. > > Only cookies: > use_only_cookies = On > use_cookies = On > > Only GET/POST: > use_only_cookies = Off > use_cookies = Off > > Both: > use_only_cookies = Off > use_cookies = On > > The remaining 4th combination should create an impossible scenario. > Does it mean to use neither option? > > I can change the proposal to deprecate only use_only_cookies=Off and > session.use_trans_sid=On and leave session.use_cookies alone, but I > just can't think of a situation when leaving that setting in PHP would > make sense. > > I am probably missing something very important and I would appreciate > it if someone could explain to me what it is. I wouldn't want to > deprecate something that is used in popular frameworks. Hi Kamil The remaining 4th combination creates the situation when session creation is always a responsibility of the userland code. (by using session_id($id)) In the link I provided it is done by PSR-7/15 purists that think that only the request emitter should handle headers, not PHP itself and it includes cookie headers. For non-purists it is still a useful scenario, for example it allowed to use SameSite attribute on a session cookie before PHP 7.3
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Friday, 1 March 2024 at 06:28, Stephen Reay wrote: > For the third time: I'm well aware of how parameter types work everywhere > else, and that's why I'm asking why the same behaviour isn't being followed > here? > > - You've said you want to avoid boilerplate; and > - You've said you would expect most people to just use the implicit > `same-type $value` parameter; and > - You've acknowledged that the existing 'standard' is that a parameter > without a type is considered `mixed`; and > - You've acknowledged in your RFC that there is a use-case for wanting to > accept a wider type than what a property stores internally. > > So why then is it so unacceptable that the existing standard be followed, > such that a set hook with an "untyped" parameter would be treated as `mixed` > as it is everywhere else? > > Yes, I know you said "widening to `mixed` is unwise". I don't seem to recall > amongst all the type-related previous RFCs, any that suggested that child > parameters widening to `mixed` (either explicitly or implicitly) should be > deprecated, so I'm sorry but I don't see much value in that argument. Deprecating this behaviour would effectively mean, types are now required everywhere, which is an unreasonable proposition. The "implicit" widening to mixed is something that got introduced _after_ typing was introduced to PHP, and quite "late" even (in 7.2) considering typing objects/arrays has existed since PHP 5. [1] I don't think it's unreasonable that if property access hooks only work on typed properties, having no type means the type of the property and if you want to widen the type you _must_ specify a type. Especially if you want the backing type to be mixed well you are just required to write a typed property with type mixed, same as readonly. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/parameter-no-type-variance
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
> > Hi Internals, > > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. > > In particular, I am looking for any feedback as to why this is a bad > idea. The primary motivation behind this RFC is to reduce potential > security pitfalls. > > Regards, > Kamil Tekiela Hi Kamil, I quite like the idea, and I think the RFC motivation, impact, and the scope is clear as well. The PHP 8.4 deprecations RFC also proposes to deprecate SID constant; perhaps it's something worth mentioning in this RFC too?
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On 27/02/2024 23:17, Larry Garfield wrote:
>
> A little history here to help clarify how we ended up where we are: The
> original RFC as we designed it modeled very closely on Swift, with 4 hooks.
> Using get/set at all would create a virtual property and you were on your
> own, while the beforeSet/afterSet hooks would not.
This is interesting to hear, because the current RFC comes across - or at least
did to me, on first reading - as "these are normal properties, and then you're
adding some magic on top of them".
The Eureka! moment for me was realising that the whole thing makes more sense
if you *start* with "virtual" properties, and then add some magic to avoid
declaring a second property to store a backing value.
This "virtual-first" view is how my current thinking is framed, which I tried
to demonstrate here: https://wiki.php.net/rfc/property-hooks/imsop-suggestion
> == Re asymmetric typing:
>
> This is capability already present today if using a setter method.
>
> class Person {
> private $name;
>
> public function setName(UnicodeString|string $name)
> {
> $this->name = $value instanceof UnicodeString ? $value : new
> UnicodeString($value);
> }
> }
I find this unconvincing. Just because this method name starts with "set",
doesn't mean everything it does should be possible in a property setter.
You could also have a method that took two arguments:
public function setName(string $first, string $last)
{
$this->name = $first . ' ' . $last;
}
Or a mandatory argument and an optional flag:
public function setName(string $name, bool $normalise=false)
{
$this->name = $normalise ? ucwords($name) : $name;
}
Neither of those are going to be translatable to property set hooks, and that's
totally fine.
> covering an easy-to-cover use case seems like a good thing to do.
This is the crux: I don't think asymmetric types *are* easy.
Firstly, they mean that every single piece of static analysis or reflection
which wants to ask "what is the type of this property" has to take into account
the new concept that the "settable type" might be different from the "gettable
type".
Secondly, they mean that a user has to understand that this code might result
in the variable magically changing type:
$me = 'Rowan';
$object->name = $me;
$me = $object->name;
// $me is now magically an object!
// how do I get my string back?
Thirdly, there's a simpler alternative, providing a separate virtual property,
which can then be readable as well as writeable:
$me = 'Rowan';
$object->nameString = $me;
$me = $object->nameUnicode;
// easily visible that we're reading a different property, with a different type
$object->nameUnicode = $me;
$me = $object->nameString;
// fully reversible, and no need to know how the object implements it
> It also ties into the question of the explict/implicit name, for the reason
> you mentioned earlier (unspecified means mixed)
Another reason to dislike it as complicating the proposal, IMHO.
> == Re virtual properties:
>
> On the downside, if you have a could-be-virtual property but never actually
> use the backing value, you have an extra backing value hanging around in
> memory that is inaccessible normally, but will still show up in some
> serialization formats, which could be unexpected.
This is a reasonable argument in favour of automatic detection.
> If you omit one of the hooks and forget to mark it virtual, you'll still get
> the default of the other operation
My immediate question here is "why?" Why does the set hook magically come into
existence, just because you defined the get hook a particular way?
Consider this example, using a virtual property:
private int $_nextId;
public int $nextId {
get { $this->_nextId ??= 0; return $this->_nextId++; }
}
This might not be the most common thing to do, but (as far as I know) it will
work. There is no direct write access to the property, but we need somewhere to
store the incrementing value.
Then we say "woof this is complicated having to make my own backing property
for all these little things; can this be simplified?" and write this:
public int $nextId {
get { $this->nextId ??= 0; return $this->nextId++; }
}
Great! We've got rid of the explicit backing field, and the code still works...
but wait! Suddenly, a setter has appeared, even though we never asked for one!
I suppose the reasoning is that it's quite common to want to implement the
default version of one or other hook; but note that with the currently proposed
short-hand the defaults can be written as:
get => $this->someName;
set($value) => $value;
If that's still too long, we can borrow from C#, where they can be written as:
get;
set;
That gives the choice of whether the default is implemented back to the user,
and removes a foot-gun inconsistency between virtual and backed properties.
> * Doing autodetection as now, but with an added "make a backing value anyway"
>
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Fri, Mar 1, 2024, at 6:28 AM, Stephen Reay wrote:
== Re the $value variable in set
>>
>> *snip*
>>
So what makes the most sense to me is to keep $value optional, but IF you
specify an alternate name, you must also specify a type (which may be
wider). So these are equivalent:
public int $foo { set (int $value) => $value + 1 }
public int $foo { set => $value + 1 }
And only those forms are legal. But you could also do this, if the
situation called for it:
public int $foo { set(int|float $num) => floor($num) + 1; }
This "all or nothing" approach seems like it strikes the best balance,
gives the most flexibility where needed while still having the least
redundancy when not needed, and when a name/type is provided, its behavior
is the same as for a method being inherited.
Does that sound acceptable? (Again, question for everyone.)
>>>
>>> My only question with this is the same as I had in an earlier reply
>>> (and I'm not sure it was ever answered directly?), and you allude to
>>> this yourself: everywhere *else*, `($var)` means a parameter with type
>>> `mixed`. Why is the type *required* here, when you've specifically said
>>> you want to avoid boilerplate? If we're going to assume people can
>>> understand that `(implicit property-type $value) is implicit, surely we
>>> can also assume that they will understand "specifying a parameter
>>> without a type" means the parameter has no type (i.e. is `mixed`).
>>>
>>> Again, for myself I'd be likely to type it (or regular parameters,
>>> properties, etc) as `mixed` if that's what I want *anyway*, but the
>>> inconsistency here seems odd, unless there's some until-now unknown
>>> drive to deprecate type-less parameters/properties/etc.
>>
>> If we went this route, then an untyped set param would likely imply "mixed",
>> just like on methods. Which, since mixed is the super type of everything,
>> would still technically work, but would weaken the type enforcement and thus
>> static analysis potential. (Just as a method param can be widened in a
>> child class all the way to mixed/omitted, and it would be unwise for all the
>> same reasons.)
>>
>
> Having a `mixed` param in the set hook shouldn't weaken the actual
> backing parameter though - when the hook writes to `$this->prop`, the
> parent type is still enforced, *surely*? If not, why not?
>
> As for how static analysis tools handle this concept - I'd have thought
> it's too early to suggest what static analysis tools will or won't
> support given how much they already support based on less-formal syntax
> like docblocks. It's *already* possible to have a property that is
> reported (to static analysis tools/IDEs/etc) as a fixed type, but
> accepts a wider type on write, with the current mish-mash of typed
> properties, docblocks, magic getters and setters, and the bizarre
> `unset` behaviour. This is simply converting that into standardised
> syntax. The RFC itself proposes a scenario where a wider type is
> accepted in the set hook. I find it hard to believe that a static
> analysis tool can model "this property is `Foo` but it accepts
> `string|Foo` on write" but not "this property is `Foo` but it accepts
> `mixed` on write". Heck if that's such a problem what is said tool
> going to do when someone *explicitly* widens the parameter to `mixed`
> in a set hook?
>
> I would argue that if the language is providing better support for
> typed properties by adding 'hooks' like this, the need for static
> analysis of those specific parts reduces greatly - if someone wants to
> accept `mixed` when storing as a string, and convert it in the hook,
> and the language can **enforce those types at runtime**, why should
> some hypothetical static analysis be a hangup for that?
>
>> In the RFC as currently written, omitted means "derive from the property,"
>> which is a concept that doesn't exist in methods; the closest equivalent
>> would be if omitting a type in a child method parameter meant "use the
>> parent's type implicitly," which is not how that works right now.
>
> For the third time: I'm well aware of how parameter types work
> everywhere else, and that's why I'm asking why the same behaviour isn't
> being followed here?
>
> - You've said you want to avoid boilerplate; and
> - You've said you would expect most people to just use the implicit
> `same-type $value` parameter; and
> - You've acknowledged that the existing 'standard' is that a parameter
> without a type is considered `mixed`; and
> - You've acknowledged in your RFC that there is a use-case for wanting
> to accept a wider type than what a property stores internally.
>
> So why then is it so unacceptable that the existing standard be
> followed, such that a set hook with an "untyped" parameter would be
> treated as `mixed` as it is everywhere else?
>
> Yes, I know you said
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
-- Forwarded message - From: Anton Smirnov Date: Sun, 3 Mar 2024 at 19:56 Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions To: Kamil Tekiela Greetings! I'm sorry for addressing you directly, if you can forward this message to internals I'd be grateful. It seems outlook is still banned and I can't re-subscribe with any other email (tried outlook, gmail, vivaldi and a small private service) On 02/03/2024 23:10, Kamil Tekiela wrote: > Hi Internals, > > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. > > In particular, I am looking for any feedback as to why this is a bad > idea. The primary motivation behind this RFC is to reduce potential > security pitfalls. > > Regards, > Kamil Tekiela 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
[PHP-DEV] [pdo_dblib] Correct TDS protocol version
Hi internals,
There seems to be an error in the handling of pdo_dblib's TDS protocol version,
so I'm thinking of fixing these. Through this email, I would like to discuss
the appropriate time and method for correction.
— For your reference —
There are several derivatives of "SQL Server", with Microsoft SQL Server being
the most popular. These communicate using the TDS protocol. However, the TDS
protocol standards are not strictly unified, and the Sybase protocol and
Microsoft SQL Server have different standards, so each is defined as a
different "version" of the TDS protocol.
Therefore, pdo_dblib allows the user to specify a "version" for dsn and select
which protocol version to use.
— End —
The related issue:
https://github.com/php/php-src/issues/13475
The types and details of protocol versions are explained in the FreeTDS user
guide:
https://www.freetds.org/userguide/ChoosingTdsProtocol.html
Summarize the explanation.
4.2: Available for older Sybase and Microsoft SQL Servers
5.0: Available for new Sybase
7.0 - 7.4: Available for new Microsoft SQL Server
Notes:
- There's actually a version too called 4.6, which appears to be for Open SQL
Server. However, I plan to explore this in a little more detail.
- It seems that there are two types of 5.0, so I will investigate this as well.
Now take a look at the pdo_dblib implementation in php-src:
https://github.com/php/php-src/blob/ffc6f192a8f475dfdff942bb22f509d1eefd0847/ext/pdo_dblib/dblib_driver.c#L447
Excerpt the incorrect part:
```
{"5.0",DBVERSION_70} /* FIXME: This does not work with Sybase, but environ will
*/
{"6.0",DBVERSION_70}
{"8.0",DBVERSION_72}
{"10.0",DBVERSION_100}
```
`DBVERSION_70` (meaning 7.0) is specified for 5.0 and 6.0. And as far as I can
tell, there is no version called 6.0. (`DBVERSION_60` is also not defined.)
There is also no version 8.0, but according to the FreeTDS user guide, it
appears that versions of FreeTDS older than 1.3 can specify this, as 7.1 was
originally planned to be released as 8.0. However, PHP treats 8.0 as an alias
for 7.2 rather than 7.1, which is incorrect anyway.
`DBVERSION_50`, which would be used for 5.0, is also not defined, but according
to the following page, `DBVERSION_100` means 5.0.
https://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc20155_1251/html/newfesd/BABHHDEI.htm
Excerpt:
> DBVERSION_100 — DB-Library is running with TDS version 5.0 protocol
So remove 6.0, 8.0 and 10.0 and 5.0 should look like this:
```
{"5.0",DBVERSION_100}
```
These changes are definitely a BC break. Therefore, I would appreciate any
feedback you may have, including which versions should I make changes to?
Regards.
Saki
[PHP-DEV] [Discussion] grapheme cluster for str_split function
Hi, Internals I noticed PHP does not have grapheme cluster for str_split function., Until now, you had to use the PCRE function's \X. Therefore, I try create `grapheme_str_split` function. https://github.com/php/php-src/pull/13580 It is possible to convert array per emoji and variation selectors using ICU. If it's fine, I'll create an RFC. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Mon, Mar 4, 2024 at 4:40 PM Stephen Reay wrote:
>
>
>
> > On 28 Feb 2024, at 06:17, Larry Garfield wrote:
> >
> > On Sun, Feb 25, 2024, at 10:16 PM, Rowan Tommins [IMSoP] wrote:
> >> [Including my full previous reply, since the list and gmail currently
> >> aren't being friends. Apologies that this leads to rather a lot of
> >> reading in one go...]
> >
> > Eh, I'd prefer a few big emails that come in slowly to lots of little
> > emails that come in fast. :-)
> >
> >>> On 21/02/2024 18:55, Larry Garfield wrote:
> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC.
> >>>
> >>>
> >>> Hello, and a huge thanks to both you and Ilija for the continued work
> >>> on this. I'd really like to see this feature make it into PHP, and
> >>> agree with a lot of the RFC.
> >>>
> >>>
> >>> My main concern is the proliferation of things that look the same but
> >>> act differently, and things that look different but act the same:
> >
> > *snip*
> >
> >>> - a and b are both what we might call "traditional" properties, and
> >>> equivalent to each other; a uses legacy syntax which we haven't
> >>> removed for some reason
> >
> > I don't know why we haven't removed `var` either. I can't recall the last
> > time I saw it in real code. But that's out of scope here.
> >
> > *snip*
> >
> >> I think there's some really great functionality in the RFC, and would
> >> love for it to succeed in some form, but I think it would benefit from
> >> removing some of the "magic".
> >>
> >>
> >> Regards,
> >>
> >> --
> >> Rowan Tommins
> >> [IMSoP]
> >
> >
> > I'm going to try and respond to a couple of different points together here,
> > including from later in the thread, as it's just easier.
> >
> > == Re, design philosophy:
> >
> >> In C#, all "properties" are virtual - as soon as you have any
> >> non-default "get", "set" or "init" definition, it's up to you to declare
> >> a separate "field" to store the value in. Swift's "computed properties"
> >> are similar: if you have a custom getter or setter, there is no backing
> >> store; to add behaviour to a "stored property", you use the separate
> >> "property observer" hooks.
> >>
> >> Kotlin's approach is philosophically the opposite: there are no fields,
> >> only properties, but properties can access a hidden "backing field" via
> >> the special keyword "field". Importantly, omitting the setter doesn't
> >> make the property read-only, it implies set(value) { field = value }
> >
> > A little history here to help clarify how we ended up where we are: The
> > original RFC as we designed it modeled very closely on Swift, with 4 hooks.
> > Using get/set at all would create a virtual property and you were on your
> > own, while the beforeSet/afterSet hooks would not. We ran that design by
> > some PHP Foundation sponsors a year ago (I don't actually know who, Roman
> > did it for us), and the general feedback was "we like the idea, but woof
> > this is complicated with all these hooks and having to make my own backing
> > property for all these little things. Couldn't this be simplified?" We
> > thought a bit more, and I off-handedly suggested to Ilija "I mean, would it
> > be possible to just detect if a get/set hook is using a backing store and
> > make it automatically? Then we could get rid of the before/after hooks."
> > He gave it a quick try and found that was straightforward, so we pivoted to
> > that simplified version. We then realized that we had... mostly just
> > recreated Kotlin's design, so shrugged happily and went on with life.
> >
> > As noted in an earlier email, C#, Kotlin, and Swift all have different
> > stances on the variable name for the incoming value. We originally modeled
> > on Swift so had that model (optional newVal name), and also because we
> > liked how compact it was. When we switched to the simplified, incidentally
> > Kotlin-esque approach, we just kept the optional variable as it works.
> >
> > I think where that ended up is pretty nice, personally, even if it is not a
> > direct map of any particular other language.
> >
> > == Re asymmetric typing:
> >
> > This is capability already present today if using a setter method.
> >
> > class Person {
> >private $name;
> >
> >public function setName(UnicodeString|string $name)
> >{
> >$this->name = $value instanceof UnicodeString ? $value : new
> > UnicodeString($value);
> >}
> > }
> >
> > And widening the parameter type in a child class is also entirely legal.
> > As the goal of the RFC is, essentially, "make most common getter/setter
> > patterns easy to add to a property without making an API-breaking method,
> > so people don't have to add redundant just-in-case getters and setters all
> > the time," covering an easy-to-cover use case seems like a good thing to do.
> >
> > It also ties into the question
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
On Saturday, 2 March 2024 at 21:10, Kamil Tekiela wrote: > Hi Internals, > > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. > > In particular, I am looking for any feedback as to why this is a bad > idea. The primary motivation behind this RFC is to reduce potential > security pitfalls. > > Regards, > Kamil Tekiela I think this makes sense to me. I would possibly move the deprecation of the SID constant from the mass deprecation RFC to this one, as I would be very odd to have this accepted but not the latter. Best regards, Gina P. Banyard
