Re: [RFC] Improve language coherence for the behaviour of offsets and containers

From: Date: Tue, 09 Jul 2024 23:39:37 +0000
Subject: Re: [RFC] Improve language coherence for the behaviour of offsets and containers
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Thursday, 4 July 2024 at 14:52, Gina P. Banyard <[email protected]> wrote:

> Hello internals,
> 
> I would like to formally open the discussion on an RFC I've been working on for the past
> year:
> https://wiki.php.net/rfc/container-offset-behaviour
> 
> As DokuWiki is a bit of a faff at times, the Markdown sources are available on GitHub:
> https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md

I have more or less finalized the implementation of the object handler part..
The JIT works, and my minimal opcache changes seem to not make everything crash.

I have added one tiny subsection to the RFC about the removal of the zend_class_arrayaccess_funcs
struct:
https://wiki.php.net/rfc/container-offset-behaviour#removal_of_the_zend_class_arrayaccess_funcs_struct_and_ce_pointer

One related issue that I found while working on this RFC is related to ext/phar:
https://github.com/php/php-src/pull/14503

A PharFileInfo extends SplFileInfo and supports directories, which SplFileInfo does not.
But Phar also allows the user to set the file info class via the setInfoClass() method.
This method takes any SplFileInfo based class, such as SplFileObject.
Thus, there is currently a bug in the extension where isset() will return true about being able to
access a string offset that points to a directory but SplFileObject will throw a LogicException that
it cannot be used with a directory.

There are two-way to fix this issue, in my PR I went with the solution to return false for the
has_dimension handler on directories if the info class is not based on PharFileInfo,
or we could remove support for setting info classes that are not based on PharFileInfo.

Let me know what you prefer, as my current implementation is based on the above PR to fix the Phar
behavioural changes.

Moreover, I know the traffic on the list has been pretty high, but I do intend to have this RFC up
for voting for inclusion in PHP 8.4, and I'm not exactly sure how I am meant to interpret the
lack of responses.

Best regards,

Gina P. Banyard


Thread (15 messages)

« previous php.internals (#124325) next »