Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion
Hi Everyone, If there are no further complaints, I intend to start the votes ( https://wiki.php.net/rfc/resource_to_object_conversion) the day after tomorrow. Regards, Máté
Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
Hi Max,
Hi, I'd like to propose a new attribute, #[NotSerializable]. This
> functionality is already available for internal classes - userspace should
> benefit from it, too.
>
> The RFC: https://wiki.php.net/rfc/not_serializable
> Proposed implementation: https://github.com/php/php-src/pull/12788
>
> Please let me know what you think.
>
Regarding the inheritance-related behavior ("The non-serializable flag is
inherited by descendants"), this is very unlike any other attributes, and
this actively prevents writing a child class that'd make a parent
serializable if it wants to.
To me, if this is really the behavior we want, then the attribute should be
replaced by a maker interface.
Then, a simple "instanceof NotSerializable" would be enough instead of
adding yet another method to ReflectionClass.
Cheers,
Nicolas
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Tue, Jan 2, 2024 at 3:46 PM Jeffrey Dafoe wrote: > > > Again, the representation as objects isn't a key requirement. Python's > > > WSGI spec simply has a dictionary (read: associative array) of the > > > environment based on CGI. The application might well turn that into a > > > more powerful object, but standardisation of such wasn't considered a > > > pre-requisite, and would actually have hampered ASGI, where not all > > > events represent an HTTP request. > > Jumping in to add that NGINX has their newish Unit app server, which uses > Yet Another Custom SAPI for PHP. > > It seems to me that its development significantly decreased after F5 takeover and the unit main developer leaving the company so not sure if there is that much future in it. Cheers Jakub
RE: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
> > Again, the representation as objects isn't a key requirement. Python's > > WSGI spec simply has a dictionary (read: associative array) of the > > environment based on CGI. The application might well turn that into a > > more powerful object, but standardisation of such wasn't considered a > > pre-requisite, and would actually have hampered ASGI, where not all > > events represent an HTTP request. Jumping in to add that NGINX has their newish Unit app server, which uses Yet Another Custom SAPI for PHP. -Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Declaring new elements as references while destructuring within a foreach() head
I don't know if this was designed this way purposefully, but it makes
sense to me. I see nothing out of the ordinary here. It makes for some
really nasty code, but that can probably be said about all code that
uses references.
If we try to simplify your example, we can see more clearly what's
happening. First, let's take the loop out of the equation.
$arr = [];
['foo' => &$v] = $arr;
$v = 1;
var_dump($arr);
This creates an array with one element whose value is 1 and key is
foo. That array restructuring is pretty much just a syntactic sugar
for an assignment operation. So we can simplify this example further
by replacing the array destructuring with this:
$v = & $arr['foo'];
Now, this looks like an average assignment of reference in PHP. The
rules of assignment-by-ref state:
> If you assign, pass, or return an undefined variable by reference, it will
> get created.
https://www.php.net/manual/en/language.references.whatdo.php#language.references.whatdo.assign
Since array elements have similar logic to plain variables, this
applies to undefined keys, too. The foo key in the example above is
created initially with a NULL value. Using the variable alias we
created, we can assign a different value to it.
Coming back to your example from SO, the array destructuring in
foreach is just a convoluted way of assignment-by-ref. After
simplifying it, it becomes:
foreach ($array as $key => $row) {
$x = & $array[$key]['new'];
$x = $row['bar'];
}
Which looks pretty normal to me. I would say it's definitely not a
bug. It's just a mix of two PHP features that together make up for
some confusing-looking code.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Declaring new elements as references while destructuring within a foreach() head
I want to ask about a quirk that I happened upon. In truth, I expected my code to fail with a fatal error, but it turns out that while using array destructuring in the head of a foreach() loop it is permitted to declare new elements if the value is a reference. Is this a bug or an intended feature? If not a bug should a note/section clarify this behavior? https://www.php.net/manual/en/language.types.array.php My demonstration can be found at this evidently unhelpful question: https://stackoverflow.com/q/77741716/2943403
