s/goot at/not good at/ sorry
2011/8/12 Laruence <larue...@php.net>: > Hi: > I am goot at debate as my poor english, > I try to make my point clearly, > > that is , I think there is one reason to do this change, that is > "what you saw should be what you get", > > this behavior confused any pepole who meet this issue first, and > need explained by document, > > I agree with Tyral:"it would be really awkward keeping this > workaround much longer for a design problem which isn't there > anymore." > > thanks > > 2011/8/12 Ferenc Kovacs <tyr...@gmail.com>: >> On Fri, Aug 12, 2011 at 3:20 PM, Derick Rethans <der...@php.net> wrote: >>> On Fri, 12 Aug 2011, Laruence wrote: >>> >>>> a request uri : http://***/a.b=2 will result $_GET["a_b"] = 2 ( >>>> the dot was translated into underscore char); >>>> >>>> my point is , since register_globals has be removed already( in >>>> my opinion this behavior only make sence when register_globals on), >>>> should we remove this translating behavior too? >>> >>> No. No reason to change anything that isn't broken. Chanhing this will >>> mean a BC break, even for people that don't use register_globals. >>> >> >> it is broken, we just sucked it up. >> if we would both provide the foo_bar and foo.bar: >> >> - if your code expects foo.bar to be foo_bar, it's there. >> - if you expect foo.bar, it's also fine. >> - if you did a workaround in the past (parse the query string >> manually), that would also work, in the worst case, you would >> overwrite the foo.bar with the same value. >> >> so it's not much userland BC (not until we remove the foo_bar syntax), >> except maybe if you do some really strict input validation (abort if >> there is an request variable not specified in the whitelist). >> I don't mind if this only ships with the next minor or major version, >> but it would be really awkward keeping this workaround much longer for >> a design problem which isn't there anymore. >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu >> > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
