Re: [PHP-DEV] Final anonymous classes

2023-05-05 Thread Levi Morrison via internals
I am not sure about making them final by default. I think it's a more consistent language design to allow `new final class()` as you originally proposed. Although I don't know why anyone would want to extend anonymous classes, we can see that people do, in fact, do it. I don't see why we couldn't a

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

2023-05-05 Thread Hans Krentel via internals
On Tuesday 02 May 2023 15:07:21 (+02:00), Rowan Tommins wrote: > On Tue, 2 May 2023 at 13:20, Máté Kocsis wrote: > > > Yes, I agree that the assert_options() name is at least weird but I > > wouldn't like to > > include changes into this RFC which are not strictly related to overloaded > > si

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

2023-05-05 Thread Tim Düsterhus
Hi On 5/5/23 18:12, Derick Rethans wrote: createFromIso8601(string $specification, int $options = 0) -> createFromISO8601String I am open to bike shedding about this :-) Okay, I'd like a different color of my bikeshed: Please no consecutive uppercase letters in the function name. I find cre

Re: [PHP-DEV] DB specific PDO subclasses questions.

2023-05-05 Thread Dan Ackroyd
On Tue, 7 Jun 2022 at 15:25, Philip Hofstetter wrote: > > On 6 Jun 2022 at 21:15:12, Dan Ackroyd wrote: >> >> 2. Other than the SQLite blobOpen functionality, does anyone know of >> any other functionality that is exposed by SQLite or Postgres that >> isn't currently exposed through the magic PDO

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

2023-05-05 Thread Derick Rethans
On Thu, 27 Apr 2023, Máté Kocsis wrote: > As you have possibly already experienced, overloaded signatures cause > various smaller and bigger issues, while the concept is not natively > supported by PHP. That's why I drafted an RFC which intends to phase > out the majority of overloaded function

Re: [PHP-DEV] Final anonymous classes

2023-05-05 Thread Derick Rethans
On Mon, 24 Apr 2023, Daniil Gentili wrote: > I've submitted https://github.com/php/php-src/pull/11126 to add > support for final anonymous classes, though as noted by iluuu1994, it > would probably make more sense to just make all anonymous classes > final by default, what do you think? Yes.

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

2023-05-05 Thread Derick Rethans
On Thu, 20 Apr 2023, Larry Garfield wrote: > Before we dig into any of those edge cases, however, we want to throw > the question out: Is this general approach even acceptable? I think I would vote against all three options. It is hard to put a pulse on, but IMO it looks too complex. I'd say: w

Re: [PHP-DEV] Proposal: native decimal scalar type support

2023-05-05 Thread Derick Rethans
On Wed, 26 Apr 2023, Alexander Pravdin wrote: > A `decimal` builtin scalar type with some predefined precision > (probably configured in php.ini). I can set the precision explicitly > like `decimal(10,4)`. Introducing a real decimal type is not an easy feat. First of all, we would probably need

Re: [PHP-DEV] [RFC] [Discussion] Clone with

2023-05-05 Thread Derick Rethans
On Mon, 17 Apr 2023, Máté Kocsis wrote: > Hi Everyone, > > Quite some time after mentioning the "clone with" construct the first time > (at the end of the > https://wiki.php.net/rfc/write_once_properties#run-time_behaviour section), > finally I managed to create a working implementation for this

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

2023-05-05 Thread Derick Rethans
On Mon, 10 Apr 2023, G. P. B. wrote: > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/co

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

2023-05-05 Thread Derick Rethans
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