Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103507 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 17815 invoked from network); 26 Nov 2018 15:03:52 -0000 Received: from unknown (HELO scarlet.netpirates.net) (188.94.27.5) by pb1.pair.com with SMTP; 26 Nov 2018 15:03:52 -0000 Received: from p5de2cba8.dip0.t-ipconnect.de ([93.226.203.168] helo=[192.168.178.42]) by scarlet.netpirates.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRF2o-0007jl-Fw for internals@lists.php.net; Mon, 26 Nov 2018 12:27:14 +0100 To: internals@lists.php.net References: Reply-To: internals@lists.php.net Message-ID: <589a0733-839b-66aa-600e-db65a8c574dd@php.net> Date: Mon, 26 Nov 2018 12:27:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Built-in classes that cannot be serialized From: sebastian@php.net (Sebastian Bergmann) 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 > unserialized), and then use it to throw (sorry, I lied). > > In any case, what's your motivation here? As long as throwing > (un)serialize/__sleep/__wakeup exist, you will not be able to determine > whether a class can be (un)serialized a priori. It may even be that a class > can only sometimes be serialized. The only reliable way to find out is to > actually try it. What prevents you from attempting (un)serialization and > catching potentially thrown exceptions? 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, too, think that classes that currently throw in __sleep() should be migrated to use zend_class_serialize_deny. Only if all classes that cannot be serialized use zend_class_serialize_deny then it would make sense to expose that information through the Reflection API.