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. In fact, there's no reason to change it as if you turn _SERVER into this layer, this would only lead to creating _REAL_SERVER containing what _SERVER used to. Instead, we could just create this layer - either as $_SAPI, or as function collection, or as object if people want it that way - does not matter, really - and let it live by itself, not encumbered by any concerns about BC and not hurting any existing apps. I do not see any downside to this approach, do you? > 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? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
