Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85421
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.45 as permitted sender)
Message-ID: <550FB623.8000209@gmail.com>
Date: Sun, 22 Mar 2015 23:43:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Dennis Birkholz <dennis@birkholz.biz>, internals@lists.php.net
References: <550FA2ED.6080000@gmail.com> <550FB0E2.7020600@birkholz.biz>
In-Reply-To: <550FB0E2.7020600@birkholz.biz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Serializing exceptions
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I think we should discuss if (un)serialization is a first-class
> operation in the language and if so, we should try to make everything
> serializable. Currently, we introduce more and more unserializable

I don't think we can, not unless we can serialize PHP code (like Java
can have JARs with bytecode). Otherwise, something like closure is
inherently not serializable. Moreover, something resource-bound is not
serializable either since it depends on something external.

> If we don't want serialization as a first-class operation, we should

I'm not sure what you mean by "first-class operation". We certainly want
most objects be serializable, and they are. But some are not, and would
never be. The question is - is Exception one of those? I think yes, but
I'd like to hear if somebody says otherwise.

> make objects not serializable by default unless they implement
> serializable or __sleep()/__wakeup() and add an is_serializable() method
> to check if an object is serializable. But currently serialization gets
> more and more unreliable/prone to runtime errors.

That's because implementers of classes are not careful to account for
serialization. However, I don't think we need any drastic changes here.
-- 
Stas Malyshev
smalyshev@gmail.com