Re: [PHP-DEV] Built-in classes that cannot be serialized

On Mon, Nov 26, 2018 at 11:47 PM Stanislav Malyshev wrote: > Hi! > > > We should migrate such cases to serialize_deny though. I think it's > pretty > > weird to explicitly implement __wakeup (signalling that yes, you can be > > unserialized), and then use it to throw (sorry, I lied). > >

Re: [PHP-DEV] Built-in classes that cannot be serialized

Hi! > We should migrate such cases to serialize_deny though. I think it's pretty > weird to explicitly implement __wakeup (signalling that yes, you can be > unserialized), and then use it to throw (sorry, I lied). Throwing in __wakeup does not signal that it can be serialized. What it says that

[PHP-DEV] Don't silence fatal errors

Hi internals, When the silencing operator @ is used, the intention is generally to silence expected warnings or notices. However, it currently also silences fatal errors. As fatal errors also abort request execution, the result will often be a hard to debug white screen of death. The most

Re: [PHP-DEV] [RFC][Discuss] Covariant return- and contravariant parameter- types

I'm waiting for it for a long time! Thank you for putting effort on this! Em seg, 26 de nov de 2018 às 19:26, Levi Morrison escreveu: > I am happy to announce my latest RFC, [Covariant Returns and > Contravariant Parameters][1], is open for discussion. If you do not > recognize those terms then

[PHP-DEV] [RFC][Discuss] Covariant return- and contravariant parameter- types

I am happy to announce my latest RFC, [Covariant Returns and Contravariant Parameters][1], is open for discussion. If you do not recognize those terms then hopefully the introduction coupled with the [examples][2] will help. Here is one snippet that demonstrates covariant return types:

Re: [PHP-DEV] Built-in classes that cannot be serialized

Am 26.11.2018 um 13:35 schrieb Nikita Popov: If I can rely on classes to throw an exception when serialize() is performed (be it through zend_class_serialize_deny or in __sleep()) then, yes, I can just try it. I believe you can rely on this. Not on any specific exception type, but the fact

Re: [PHP-DEV] Built-in classes that cannot be serialized

On Mon, Nov 26, 2018 at 12:27 PM Sebastian Bergmann wrote: > Am 26.11.2018 um 12:20 schrieb Nikita Popov: > > Apart from serialize_deny, a pretty common pattern is throwing __wakeup. > > See for example CURLFile. > > > > We should migrate such cases to serialize_deny though. I think it's >

Re: [PHP-DEV] declare(cache=0) - explanation

On 11/26/18 2:14 PM, Nikita Popov wrote: > On Mon, Nov 26, 2018 at 10:15 AM Zeev Suraski wrote: > >> On Sun, Nov 25, 2018 at 11:43 PM Marco Pivetta wrote: >> >>> Is that space rrreally a problem? >>> >>> Take the example ZF loader from the RFC: that barely makes any difference >>> at

Re: [PHP-DEV] Built-in classes that cannot be serialized

Am 26.11.2018 um 12:20 schrieb Nikita Popov: Apart from serialize_deny, a pretty common pattern is throwing __wakeup. See for example CURLFile. We should migrate such cases to serialize_deny though. I think it's pretty weird to explicitly implement __wakeup (signalling that yes, you can be

Re: [PHP-DEV] Built-in classes that cannot be serialized

On Mon, Nov 26, 2018 at 10:28 AM Sebastian Bergmann wrote: > The following classes register zend_class_serialize_deny: Closure, COM, > DOTNET, Generator, HashContext, Reflection, ReflectionClass, > ReflectionClassConstant, ReflectionExtension, ReflectionException, > ReflectionFunction,

Re: [PHP-DEV] declare(cache=0) - explanation (was: Re: [PHP-DEV] [mini-RFC] Disable opcache per script using "declare(cache=0)")

On Mon, Nov 26, 2018 at 10:15 AM Zeev Suraski wrote: > On Sun, Nov 25, 2018 at 11:43 PM Marco Pivetta wrote: > > > Is that space rrreally a problem? > > > > Take the example ZF loader from the RFC: that barely makes any difference > > at all. > > > > A stronger reasoning for another

[PHP-DEV] Re: Built-in classes that cannot be serialized

On 26.11.2018 at 10:27, Sebastian Bergmann wrote: > The following classes register zend_class_serialize_deny: Closure, COM, > DOTNET, Generator, HashContext, Reflection, ReflectionClass, > ReflectionClassConstant, ReflectionExtension, ReflectionException, > ReflectionFunction,

Re: [PHP-DEV] declare(cache=0) - explanation (was: Re: [PHP-DEV] [mini-RFC] Disable opcache per script using "declare(cache=0)")

On Mon, 26 Nov 2018 at 09:15, Zeev Suraski wrote: > The goal of declare(cache=0) would be to avoid persisting utility > functions/classes that have to do with a particular preload.php > implementation - so that they don't become a part of the app's memory > context and 'pollute' its scope. >

[PHP-DEV] Built-in classes that cannot be serialized

The following classes register zend_class_serialize_deny: Closure, COM, DOTNET, Generator, HashContext, Reflection, ReflectionClass, ReflectionClassConstant, ReflectionExtension, ReflectionException, ReflectionFunction, ReflectionFunctionAbstract, ReflectionGenerator, ReflectionMethod,

Re: [PHP-DEV] [mini-RFC] Disable opcache per script using "declare(cache=0)"

On Sun, Nov 25, 2018 at 6:04 PM Sara Golemon wrote: > On Sat, Nov 24, 2018 at 11:03 PM Marco Pivetta wrote: > > > Adding to the pile of "it's an edge case", since the preload scripts will > > be procedural, wouldn't it be sufficient to call > > `opcache_invalidate(__FILE__)` at the end of them?

[PHP-DEV] declare(cache=0) - explanation (was: Re: [PHP-DEV] [mini-RFC] Disable opcache per script using "declare(cache=0)")

On Sun, Nov 25, 2018 at 11:43 PM Marco Pivetta wrote: > Is that space rrreally a problem? > > Take the example ZF loader from the RFC: that barely makes any difference > at all. > > A stronger reasoning for another language construct (that changes engine > behaviour) is kinfa required. >