Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
Hi Tim, > This is already the case. `exit` throws an internal uncatchable Exception. > Quoting from the RFC: Thanks, I had overlooked that. I have no other concerns. Regards, Saki
Re: [PHP-DEV] Re: [RFC] [Discussion] Add openStream() to XML{Reader,Writer}
On 10/05/2024 16:31, Larry Garfield wrote:
> On Fri, May 10, 2024, at 2:03 PM, Niels Dossche wrote:
>> On 22/04/2024 20:41, Niels Dossche wrote:
>>> Hi internals
>>>
>>> I'm opening the discussion for my RFC "Add openStream() to
>>> XML{Reader,Writer}".
>>> RFC link: https://wiki.php.net/rfc/xmlreader_writer_streams
>>>
>>> Kind regards
>>> Niels
>>
>> Hi internals
>>
>> It's been over two weeks since I opened the discussion.
>> Please raise any last concerns now.
>> I'd like to start voting next week Monday.
>>
>> Kind regards
>> Niels
>
> Please include some examples of what a full usage would look like with the
> new additions. I'm not super experienced with those libraries right now, but
> the "create the object, THEN populate it with its data source" pattern feels
> very weird to me. (Though at least it's consistent now rather than as it was
> before, thanks.)
>
> --Larry Garfield
Hi Larry
I added minimal examples for both.
The streams I used are just the memory and output streams for simplicity so
that it can be tested on its own.
Kind regards
Niels
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
Hi On 5/9/24 17:18, Saki Takamachi wrote: Is it nonsense to always stop processing even if an error occurs? Or, how about creating an uncatchable exception class specifically for exits? Or is this level of risk negligible? This is already the case. `exit` throws an internal uncatchable Exception. Quoting from the RFC: Finally, the need for exit() to be a language construct with its own dedicated opcode is not a requirement any more since PHP 8.0 as the opcode throws a special kind of exception which cannot be caught, 2) nor executes finally blocks, to unwind the stack normally. Best regards Tim Düsterhus
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
Hi
On 5/9/24 16:27, Larry Garfield wrote:
I support this. My only question (which applies to current exit() as well), is
what the exit code is when you pass a string as the parameter. That's not
clear from the exit() docs currently, but the RFC made me wonder. (This may be
just a doc fix and we move on with life.)
If a string is passed, the exit_status is left untouched [1]. In
practice this should always result in an exit status of 0, because I
can't see how the exit_status would be non-zero before `exit("foo");`
successfully executes.
Best regards
Tim Düsterhus
[1]
https://github.com/php/php-src/blob/f88fc9c6e8262fe48eb9cf078e32e63af19047f2/Zend/zend_vm_def.h#L7541-L7570
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
Hi
On 5/9/24 16:17, Jorg Sowa wrote:
I don't think there are any other "functions" like this.
What about list(), isset(), print(), echo(), require(), include(), unset(),
empty()? We use them the same way as functions, but those are not real
functions.
All of them require to be followed by an expression (or some other
non-empty token), thus they do not act like constants the same way
'exit' and 'die' do:
- unset, isset, empty, list must be followed by '('.
- echo is a statement and needs to be terminated with ';'.
- print is an expression and requires a single non-empty expression.
- The include family is an expression and requires a single non-empty
expression.
Best regards
Tim Düsterhus
PS: Today I learned that echo and print are not aliases.
Re: [PHP-DEV] Stricter requirements for libxml
Am 10.05.2024 um 17:51 schrieb Niels Dossche: Please let me know what you think. +1
[PHP-DEV] Stricter requirements for libxml
Hi internals Libxml is used as the underlying library for many PHP extensions. Interestingly, libxml can be built with supports for various features disabled. E.g. you can build libxml without XPath, Schemas, HTML, ... support. In that case, these features are unavailable in PHP. E.g. some classes may not be defined or functions may emit a warning instead of performing an action. I'm thinking of proposing an RFC that puts stricter requirements on libxml at build time. That would make such features a requirement during PHP's build process. This will simplify maintenance and will also make sure that users can rely on these functionalities to always be available. Please let me know what you think. Kind regards Niels
Re: [PHP-DEV] Re: [RFC] [Discussion] Add openStream() to XML{Reader,Writer}
On Fri, May 10, 2024, at 2:03 PM, Niels Dossche wrote:
> On 22/04/2024 20:41, Niels Dossche wrote:
>> Hi internals
>>
>> I'm opening the discussion for my RFC "Add openStream() to
>> XML{Reader,Writer}".
>> RFC link: https://wiki.php.net/rfc/xmlreader_writer_streams
>>
>> Kind regards
>> Niels
>
> Hi internals
>
> It's been over two weeks since I opened the discussion.
> Please raise any last concerns now.
> I'd like to start voting next week Monday.
>
> Kind regards
> Niels
Please include some examples of what a full usage would look like with the new
additions. I'm not super experienced with those libraries right now, but the
"create the object, THEN populate it with its data source" pattern feels very
weird to me. (Though at least it's consistent now rather than as it was
before, thanks.)
--Larry Garfield
[PHP-DEV] Re: [RFC] [Discussion] Add openStream() to XML{Reader,Writer}
On 22/04/2024 20:41, Niels Dossche wrote:
> Hi internals
>
> I'm opening the discussion for my RFC "Add openStream() to
> XML{Reader,Writer}".
> RFC link: https://wiki.php.net/rfc/xmlreader_writer_streams
>
> Kind regards
> Niels
Hi internals
It's been over two weeks since I opened the discussion.
Please raise any last concerns now.
I'd like to start voting next week Monday.
Kind regards
Niels
