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 would
defeat the purpose of this feature.
I'm looking forward to nested classes though.
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 where
they are used ... so in fact there's nothing wrong with the vast majority
of applications using serialization of anonymous class objects.
yeah, and you can't autoload that, and if you move the instanitation of an
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 do
understand why is that, but it is not what most people would guess), which
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 way
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; if
the reason people are voting no is really that "we need to concentrate on
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 bin
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 appealing,
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_