> 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
