[PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension
Voting has now started for the RFC "Use exceptions by default in SQLite3 extension": https://wiki.php.net/rfc/sqlite3_exceptions The vote is open for 2 weeks. Thanks to the people who wrote the RFC howto page :) BohwaZ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Property hooks, nee accessors
Ilija Tovilo and I would like to offer another RFC for your consideration. It's been a while in coming, and we've evolved the design quite a bit just in the last week so if you saw an earlier draft of it in the past few months, I would encourage you to read it over again to make sure we're all on the same page. I'm actually pretty happy with where it ended up, even if it's not the original design. This approach eliminates several hard-to-implement edge cases while still providing a lot of functionality in one package. https://wiki.php.net/rfc/property-hooks -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: PHP 8.1 and OpenSSL
"Christoph M. Becker" in php.internals (Wed, 18 Jan 2023 13:20:41 +0100): >Hi all! > >While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP >8.1 builds are still using OpenSSL 1.1.1. However, OpenSSL 1.1.1 is >only supported till 2023-09-11[1], while PHP 8.1 is supported till >2024-11-25[2]. Although I don't like bumping the OpenSSL version in the >middle of PHP 8.1's lifetime, I suppose it is necessary to avoid falling >behind security support. And if we do that bump, we better do it sooner >than later. > >So, if there are no unforeseen problems, I suggest to build PHP >8.1.16RC1 with OpenSSL 3.0 (PHP 8.1.15RC1 has already been built with >OpenSSL 1.1.1). I do not mind, but I just noticed that even the official PHP 8.1.19 RC1 still ships with OpenSSL 1.1.1. What is the status? -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Define proper semantics for range() function
On Fri, 5 May 2023 at 15:49, Derick Rethans wrote: > On Mon, 27 Mar 2023, G. P. B. wrote: > > > While working on analysing the impact of the changes proposed by > > amending the behaviour of the increment and decrement operators ( > > https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that > > the range() function has some rather lax behaviour that is very > > unintuitive. > > > > I therefore propose the "Define proper semantics for range() function" > > RFC to address the unintuitive behaviour that sees no usage and/or > > hide bugs: https://wiki.php.net/rfc/proper-range-semantics > > | If $step is a float but is compatible with int interpret it as an > | integer. > > I guess you mean with that "the fraction is '.0'" and "-2^52 < number < > 2^52" ? What is also going to be playing up is the range of $start and > $end itself. > Yes, this is what I mean by "compatible with int". > | Introduce and use a proper ZPP check for int|float|string $start and > | $end parameters, this will cause TypeErrors to be thrown when passing > | objects, resources, and arrays to range(). > > I am not sure whether it wise to disallow resources. These are often > file descriptors and having a range on those *could* make sense? Not > fussed much either way though. > This is not how file/stream resources work. The resource number is not correlated to the file descriptor. The only cases where this is the case are the predefined streams STDIN, STDOUT, and STDERR. This is part of the reason for needing a new function like the file_descriptor() function I'm proposing. [1] > | Throw a ValueError when passing a negative $step for increasing > | ranges. > > I think that's a BC break that is not worthy of making. > There is no impact shown, and it doesn't make sense to pass a negative $step. This can be changed to a deprecation but considering there is no impact I don't see why we should wait. | Emit an E_WARNING when $start or $end has more than one byte. > > Surely only if the string doesn't represent an int or float? > Yes, this was implied. As we are only concerned about the "pure string" case here. But I have clarified this. | var_dump(range(null, 2)); > > I think that safely can be interpreted as range(0, 2) — I wouldn't throw > a deprecation warning for that... but then of course, we do already have > a similar (deprecation) warning for arguments. > The deprecation is just a consequence of finally using ZPP, thus invoking the previously accepted RFC. > > The change propose to throw TypeErrors and ValueErrors for case where I > > couldn't find occurrences in the wild and hide bugs, and emit some > > E_WARNINGs for cases that are hard to detect via static analysis. > > | Target Version: PHP 8.3 > > In my opinion that's not a good thing. There are a fair amount of BC > breaks (beyond the one that I oppose to with nagative steps throwing an > ValyeError), without first having deprecations. IMO, the actual BC > breaks here should become deprecations in 8.X and BC can only be really > broken in 9.0. Disagree, the implementation is already complicated, and trying to support the current absurd behaviour is impractical, especially as no impact has been found. Best regards, George P. Banyard [1] https://wiki.php.net/rfc/file-descriptor-function
[PHP-DEV] Re: Limit write access to object function parameters
2023-05-06 12:55 GMT+02:00, Olle Härstedt :
> Heyo internalitos,
>
> I was thinking of having the possibility to use `readonly` (or any
> other keyword) to make a function argument behave as if it was a
> readonly object.
>
> class Point
> {
> public int $x;
> public int $y;
> }
> function doThing(readonly Point $p)
> {
> $p->x = 10; // Not allowed
> }
>
> In C# it's called in/out/ref types:
> https://www.pluralsight.com/guides/csharp-in-out-ref-parameters
>
> The main use-case is to not give away more access than you have to,
> and being able to state your intent in the function signature.
>
> Another alternative would be to allow properties in interfaces, and
> then define a readonly-like interface:
>
> interface ReadonlyPoint
> {
> public readonly int $x;
> public readonly int $y;
> }
> function doThing(ReadonlyPoint $p)
> {
> $p->x = 10; // Not allowed
> }
>
> No idea about practical feasability.
>
> Since arrays are value types, they're not really relevant for this
> suggestion. Same goes for string, int, etc.
>
> Regards
> Olle
Also related is Object.freeze from JS (I was told):
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
