Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69536
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.220.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH6Vk7Qdpq4m3hA-38TC1REhc5skK80dJBtCcVD6gEAcUg@mail.gmail.com>
References: <ED.DC.24156.DB452525@pb1.pair.com>
	<CAF+90c_KbYKZP+KAj2Z8HFq+ceGO_17P3jk-FycjP1dBvHXjWA@mail.gmail.com>
	<525283A7.50303@php.net>
	<83.12.24156.54982525@pb1.pair.com>
	<CAPg3Xx+XAQi9b1mCwnK59hnykAAJyGj0BwyazcWzn3NXHiM4jw@mail.gmail.com>
	<52550CB7.5040309@php.net>
	<CAH-PCH5=kXweQM2VZ58EU_3ML2_qU8+gVLC=1HeJrZ-2vWmyfA@mail.gmail.com>
	<5255405D.4090402@php.net>
	<CAH-PCH6Vk7Qdpq4m3hA-38TC1REhc5skK80dJBtCcVD6gEAcUg@mail.gmail.com>
Date: Wed, 9 Oct 2013 13:29:30 +0100
Message-ID: <CAL=_i_k0Gs1E+qdaf97xmwGY13Z2UeBJKOzwDA0DP=nCV53u=w@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Joe Watkins <krakjoe@php.net>
Content-Type: multipart/alternative; boundary=047d7b343eca797d1004e84e098a
Subject: Re: [PHP-DEV] Vote: Anonymous Classes
From: pthreads@pthreads.org (Joe Watkins)

--047d7b343eca797d1004e84e098a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just quick note ... If you autoload a class which in turn unserializes an
object of an anonymous class autoloading will not be invoked for the
anonymous class ... It is compiled when you load the super / outer class
... Am out and about on phone ... I think these kinds of issues can be
explained / resolved ...
On 9 Oct 2013 13:18, "Ferenc Kovacs" <tyra3l@gmail.com> wrote:

>
>  I have voted no based on the lack of support for
>>> serialization/unserialization, and I think that we agreed that without
>>> somehow naming the class, we can't support that, and having a name woul=
d
>>> defeat the purpose of this feature.
>>>
>>> I'm looking forward to nested classes though.
>>>
>>>  Tyrael,
>>
>>         As mentioned in the RFC, there's nothing stopping you from
>> serializing an anonymous class.
>>         Anonymous classes are named, they _have_ to be; they are named
>> after the codepath (so file/function/class) prefixed with namespace wher=
e
>> they are used ... so in fact there's nothing wrong with the vast majorit=
y
>> of applications using serialization of anonymous class objects.
>>
>
> yeah, and you can't autoload that, and if you move the instanitation of a=
n
> anonymous class the generated internal classname will be different.
> and that is all fine for handling the instance in that specific request,
> but makes any attempt to persist and restore really fragile.
> I also think that anonymous classes and functions should be similar in
> this sense, and currently we don't allow the serialization of Closure
> instances(but we do allow the serialization of create_function(), and I d=
o
> understand why is that, but it is not what most people  would guess), whi=
ch
> is a bit sucky, because you have to remember, that closures work the same
> way as any other callable, except that it can't be serialized (but it can
> be json_encoded and it will result in an empty object).
> I think that having such restrictions, when something almost works the wa=
y
> one would expect is wrong.
>
>
>>
>>         Nested classes is more complicated than anonymous ones, if this
>> doesn't get in on a vote I don't see nested classes getting in either; i=
f
>> the reason people are voting no is really that "we need to concentrate o=
n
>> bugs", then what is really the point in preparing another RFC before 5.6=
 is
>> out in the wild ...
>>
>
> anonymous classes and nested classes have a bit different usecases, hence
> supporter base, I think you shouldn't guess on the result for that based =
on
> the feedback on anonymous classes.
>
>
>>
>>         I hear the syntax sugar thing ... but it's starting to wear a bi=
n
>> thin, it's a phrase thrown around without much justification or thought:
>> Almost everything you add at the Zend level which requires some kind of
>> syntax (so, pretty much everything) can be described as syntactic sugar.=
 It
>> is only a parser modification, but that should only make it more appeali=
ng,
>> we aren't asking anything new of Zend ...
>>
>
> I didn't bring up this point, but I do agree that having changes in the
> ZE/parser should be done with a good reason, and simply because it could
> have a much wider impact area and less people familiar with fixing those
> kind of bugs.
>
>
>>
>>         In any case, I appreciate the input :)
>>
>
> and we appreciate your work on improving php. _o_
>
> --
> Ferenc Kov=E1cs
> @Tyr43l - http://tyrael.hu
>

--047d7b343eca797d1004e84e098a--