Unless we're missing some problem I agree with Rasmus here. I don't see much advantage in changing this. Of course, there might be a reason.... Andi
At 10:40 AM 10/9/2002 -0700, Rasmus Lerdorf wrote: >On Wed, 9 Oct 2002, Sascha Schumann wrote: > > > I'd like to do a collective rethink of this. The simple description of > > > the session_register() function in the manual is: > > > > This description was correct initially (I wrote it), but has > > not been updated as the session module was extended. I've > > noticed this documentation issue in the earlier thread, but > > have not come around to fix it yet. > > > > If I may refer you to the session index page again, that one > > clearly stated since the beginning that the behaviour > > changes, depending on register_globals. > > > > Now, if your application(s) rely on this feature and you > > don't want to change them, you can always disable the > > warning. > >I am not talking about just mine. I am talking about a sizeable subset of >all PHP apps that use sessions. My problem here is that I do not >understand the reasoning for not continuing to allow session_register to >work on global variables regardless of the register_globals setting. I >do not see the benefit of changing this. > > > > make the function behave exactly as described in the short description. > > > > I suggest we fix the documentation. > > > > > 2. changing this breaks BC > > > > I'm not aware of any BC issues. If you have a test case, > > I'll be happy to look at it. > >The fact that we spew a warning is a pre-cursor to breaking BC. If the >plan is not to break BC on this issue then there is absolutely no reason >for adding this warning and it should be removed. > >-Rasmus > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
