I have just recently began pulling together some of the project work I have done to build a little library of tools. In doing so I have made a number of functions from what used to be separate include files... yes, I'm transitioning from linear programming to that new-fangled functional programming style. <grin> One of the components I was working on today was a user login tool. Unfortunately I re-aquainted myself with the problems that I fought with but forgot about when I wrote this code months ago. [my solution months ago was to not use functions or classes in this code, which was cumbersome and ugly] The following is from http://www.php.net/manual/en/function.session-register.php and explains it well: - - - - [EMAIL PROTECTED] 03-Jan-2001 01:37 Some note about session_register() scope. I ecountered problems while trying to register varible inside a function in one of my classes in my web application. Apparently this function can only be properly called from the scope of the page, not from some functions on that page: [...snip...] - - - - To paraphrase, session_register() does not follow proper scoping rules when identifying it's parameters. I find this to be an odd language design decision because the developers created funtions and classes which conform to a satisfactory scoping policy but when they added session vars, they did not make session vars use that scoping policy at all. Instead the session_register function looks at the $GLOBALS, and matches from this 'scope' only. That seems like a problem to me, but it has been around so long that I fear it is now a 'feature' of the language. I have trouble fathoming that this would indeed have been an unintentional result, so I am not considering it a 'bug'. Can someone explain the logic behind this to me? I don't see why session_register() behaves as it does. I should not need to globalize my local variables in order to register them with the session. I even thought of a way to 'fix' this without breaking everyone's legacy work, I think. We have all these associative arrays for grouping variables (scoping them, if you will) in $GLOBALS, $HTTP_POST_VARS, $HTTP_GET_VARS, $HTTP_SESSION_VARS, etc... why not make another global associative array $LOCAL which contains variables with strictly local scope, whatever that scope may be (and for which we never need to write "global $LOCAL"). No small task, but it would provide another way to explicitly work in a local_only scope in the context of conflicting names, etc. Then I *ought* to be able to do something like the following to register the session variable: $val <?PHP start_session(); function defoo($bar) // this is a TOY example, but the principle holds. Some data, available in a function, needs // to be registered. It is inappropriate to make $val a global, not to mention poor technique. { $val = $bar - 1; session_register($LOCALS['val']); } ?> Can anyone point at this and tell me why it SHOULD NOT happen? Does anyone have an elegant work-around for me that negates the need for $LOCALS? If not, I would feel OK passing this off towards the development team and working with them on it to improve the language. please CC your reply to: nepolon AT worlddomination DOT net thanks, --Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
