Re: [PHP-DEV] Local constants

On Sep 5, 2024 at 5:46 PM, wrote: > Block-scoping doesn't have to allow shadowing of names, How exactly would that work? Are you suggesting to restrict the use of variable names to one per function but still allow for block scoping? Or if not, how would an inner block variable $x not shadow

Re: [PHP-DEV] Local constants

On 5 September 2024 16:53:32 BST, Mike Schinkel wrote: > >Not convinced? At least one other person has my same view of the dark despair >of block-scoping: > >https://forum.golangbridge.org/t/warning-for-accidental-variable-shadowing-with-block-scope/4715 > >Of all the Go code I have written, I

Re: [PHP-DEV] function autoloading v4 RFC

On Thu, Sep 5, 2024, at 21:03, Jakob Givoni wrote: > > > On Wed, Sep 4, 2024 at 9:18 PM Rob Landers wrote: >> __ >> On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: >>> 2. I've removed artificial restrictions on the constants in which all functions that take them can accept both a

Re: [PHP-DEV] function autoloading v4 RFC

On Thu, Sep 5, 2024, at 21:03, Jakob Givoni wrote: > > > On Wed, Sep 4, 2024 at 9:18 PM Rob Landers wrote: >> __ >> On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: >>> 2. I've removed artificial restrictions on the constants in which all functions that take them can accept both a

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hello Philip, Thank you for your RFC, which is a great effort to improve serialization in PHP. Generators are indeed super useful and working with them should not be confusing. I regret that I missed your previous emails, but I would like to suggest that you consider the following concerns: 1. T

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> So if we had a #[NotSerializable] attribute (which I agree might be a good > idea) it would be implemented by setting the ZEND_ACC_NOT_SERIALIZABLE flag > on a class definition, and if this RFC passes, it would automatically apply > to json_encode() as well as serialize(). > My mistake, I hav

Re: [PHP-DEV] function autoloading v4 RFC

On Wed, Sep 4, 2024 at 9:18 PM Rob Landers wrote: > On Wed, Sep 4, 2024, at 17:16, Jakob Givoni wrote: > > > > 2. I've removed artificial restrictions on the constants in which all > functions that take them can accept both at the same time and behave > appropriately. > > > I'm not a big fan pass

[PHP-DEV] Update OpenSSL *minor* version on Windows?

Hi all, I've mentioned this already in a pull request[1], but figure this should be discussed on the mailing list. Quoting myself from that PR: | PHP 8.4 is supposed to be supported until 31st Dec 2028, but OpenSSL | 3.0 will only be supported until 7th September 2026. This might even | be an is

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Thu, 5 Sep 2024, at 17:03, John Coggeshall wrote: > I would suggest we take a step back from this and look at it with a bit more > of a wider lens. It seems to me that this would be a good place to have an > attribute (e.g. `#[NotSerializable]` ) that could be defined for any class > (with `

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> As per my previous email to the list, I have now created the official RFC to > deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. I would suggest we take a step back from this and look at it with a bit more of a wider lens. It seems to me that

Re: [PHP-DEV] Local constants

> On Sep 4, 2024, at 5:41 PM, Rob Landers wrote: >> > On Sep 4, 2024, at 16:45, Rob Landers > > > wrote: >> > >> > I think, conceptually, this makes sense, but maybe I'm the only one who >> > writes >> > >> > $arr = doSomething(); >> > $arr = array_map(fn($x) => $x->

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hello Rob, > To add to this, we apparently use json_encode at work to serialize custom > exceptions, which appears to work. This RFC would break that, I think. > > Exception is not marked as ZEND_ACC_NOT_SERIALIZABLE and would not be affected. Philip

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Thu, Sep 5, 2024, at 10:55, Alexandru Pătrănescu wrote: > > On Tue, Sep 3, 2024 at 2:27 PM Philip Hofstetter > wrote: >> Hello, >> >> As per my previous email to the list, I have now created the official RFC to >> deprecate calling json_serialize() on instances of classes marked with >>

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Tue, Sep 3, 2024 at 2:27 PM Philip Hofstetter wrote: > Hello, > > As per my previous email to the list, I have now created the official RFC > to deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. > > https://wiki.php.net/rfc/deprecate-json_encod

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

Hello Rob, I think it would be good to list these non-serializable objects in the RFC. > It doesn't have to be exhaustive, but the list includes throwables, > weak-maps, weak-references, closures, fibers, etc. Some people may be > relying on this behavior (and I'd be curious to know that use cas