Re: Vote: Anonymous Classes

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 would >>> 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 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_ > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >