Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.47 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <6D.71.03575.86970425@pb1.pair.com>
References: <D9.10.12097.032EF325@pb1.pair.com>
	<6D.71.03575.86970425@pb1.pair.com>
Date: Mon, 23 Sep 2013 21:13:50 +0100
Message-ID: <CAEKnhAFeGv0dR8QCiOpQxz4vTyWRZbQ8tusHaf6d9gJ4CH1QWA@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec548a40d96f79c04e712a86e
Subject: Re: [PHP-DEV] Re: RFC: Anonymous Classes
From: bukka@php.net (Jakub Zelenka)

--bcaec548a40d96f79c04e712a86e
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Serialization:
>
>   As I have said, serialization does work, and unserialization does work
> ...
>
>   Classes do have unique names, so as long as the entry is present upon
> unserialize you will get the object you expect ... if the entry is not
> present unserialization will fail silently.
>
>   The same kind of thing can happen where you have declared a class based
> on some predicate, whose value has changed upon unserialize and so the
> entry is not present ...
>
>   I'm not sure it is necessary to force any particular behaviour for
> serialization, it depends entirely on the application whether or not the
> entry is present upon serialization, it should be left down to the
> programmer.
>

sorry if I missed something when I read your patch but the name of the
class is defined as Class$$%lu where %lu is substituted by the current
compiler global variable anon_class_id that is incremented before. This
could lead to the unexpected results when the script that unserialize
objects define anonymous classes in different order than serializing
script. Then you can get completely different definition. In most cases you
would get when you try to use some method that are not defined but you
could also have something like this:

serialize script
<?php
$a = new class() { public $a = 100; public function foo() { echo $a + 1; }
} // class name: Class$$1
$b = new class() { public $a = 0; public function foo() { echo $a - 1; } }
// class name: Class$$2
$str = serialize(array($a, $b)); // str:
a:2:{i:0;O:8:"Class$$1":1:{s:1:"a";i:100;}i:1;O:8:"Class$$2":1:{s:1:"a";i:0;}}
save_str_to_db($str);
$a->foo(); // 101
$b->foo(); // -1

unserialize script
<?php
new class() { public $a; public function foo() { echo $a - 1; } } // class
name: Class$$1
new class() { public $a; public function foo() { echo $a + 1; } } // class
name: Class$$2
$str = load_str_from_db();
list($a,$b) = unserialize($str);
$a->foo(); // 99
$b->foo(); // 1

I know that this just a non-sense example but there could be some more
complex situations that this could happened. You will get different result
just because the classes are defined in different order...

As I said I could miss something but if this is the case I think that the
serialization issue should be addressed in the patch.


Jakub

--bcaec548a40d96f79c04e712a86e--