On 30 July 2017 20:21:01 BST, Stanislav Malyshev <smalys...@gmail.com> wrote: >Hi! > >> My point was that if we were considering a compatibility break >> anyway, we should look at separating out those common use cases into >> something higher level. > >I'm completely in agreement with you here, except for "compatibility >break" part. The good news is that you do not need any compatibility >breaks! If you want to create API that allows easy standardized access >to the common denominator of web requests - and I do not disagree it >would be a good thing! - you do not need to change _SERVER.
A good point. Of course, "if" doesn't have to be symmetrical, so perhaps I should say that if we plan to break compatibility, we should definitely do this; if we don't plan to, we should maybe do it anyway. >> Having done that, we could even allow the low-level "raw server vars" >> (not under the name $_SERVER) to drift even further > >Why not under the name _SERVER? In general, I always think that when splitting something, you should rename both parts, not keep one. Code using the retained name will continue to partly work but have odd bugs, rather than completely failing until someone reviews which replacement is appropriate. But in reality, you might want to keep $_SERVER around for compatibility anyway, so there'd be no point having 3 different versions of the same thing. The only advantage of a new name at that point would be if we decided to get rid of the shared nothing, global request state model. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
