I'm forwarding my mails which I managed to only address for Rowan: Hi Rowan,
> If we go down that route, perhaps we should come up with a corresponding > name for the object based version - "session_set_handler_object" perhaps? > That would also mean the deprecation messages can be much simpler: if > you're using the old name, you need to do something. > Hmm, that's also a very good idea, and I support this. However, I'm hesitant to deprecate the 2 parameter version of session_set_save_handler() just yet, since doing so would mean that everyone using sessions has to use a new function... Instead, I opted for aliasing it to the new session_set_handler() function (I'm not fond of the "_object" postfix, because I regard it unnecessary as it operates on SessionHandlerInterface instances). And we could maybe deprecate session_set_save_handler() altogether in a few years. Then I guess we should just pack up and go home, because right now PHP > doesn't even have an official static analyser, let alone a mandatory one; > and the evolution of Hack shows just how much the language would need to > change for such a tool to guarantee full coverage. > I'm not 100% sure an official static analyser would be needed. I think it's already a good situation to have very well usable and maintained userland implementations, which we do have. After all, we neither bundle Composer or PHPUnit. To expand on my previous statement in my other main: I don't say that everyone uses static analysers.... I know many people don't... My message would have rather been that bugs don't cost enough for these projects if they don't have to actively prevent the introduction of bugs via static analysis. I have realized in the meanwhile though that there may be many other reasons why someone doesn't use these tools, so I think this argument of mine is invalidated. I think Claude is taking the same premise, and reaching a different > conclusion: returning true is consistent with the other methods on the > class, and that consistency makes it more predictable and more accessible. > However, as George highlighted (I also tried, but most probably I couldn't convey my message), declaring true return types is an intermediary step before changing them to void. So replacing the old IntlCalendar methods having "incorrect" return types with new ones having the "correct" return types is a very nice by-product of this RFC, since we (and users) don't have to deal with the return type migration separately at a later point of time. I still think that the benefit of immediately using void for the new methods outweighs the risks. Regards: Máté
