Re: [Phplib-users] php4 session fix, and some thoughts

[Lindsay H. <fmo...@fm...>]

Thus spake Giancarlo on Fri, Jan 24, 2003 at 04:26:45AM CST
> 
> There is an unresolved problem with phplib and php4 session wether it's 
>  earlier than 4.2 (? not sure), when $_SESSION was introduced. So we 
> have a session4 class that is OK with php4 session from version 4.2(?) 
> on, but not earlier. But in this all, I think adopting *both* $GLOBALS 
> && $_SESSION (even if $_SESSION didn't exist at that time) should still 
> work, but couldn't find time to try it yet 'cause for testing I need 
> both 4.06 and 4.23 on.

PHP4 session management in phplib has to be alpha and beta until the
underlying API settles down and becomes stable.  It looks like this has
happened now, mostly, which is why I'm trying to install it on working
sites.

> Am I wrong to think that if we'd globalize all persistent vars as phplib 
> did, we could be quite well off of this problem? I mean, if we'd always 
> used $GLOBALS, and keep it always paired with $_SESSION  we shouldn't 
> have any problem with both 4.06 and 4.23... at least on the paper... for 
> incumbrant as it may be, $GLOBALS was already there before $_SESSION, 
> and the latter is only a new $GLOBALS-like array...

Don't know about previous versions of php4.  I know, from the user comments
in the php docs, that you can't put a variable into the session data from
within a function or method unless it's declared to be global.  Inserting it
into the $_SESSION array apparently isn't enough.
 
> the $_PHPLIB array exists, and is not persistent.

This  name was just an example.  Any name could be used.  My point is that
some sort of easily recognizable name prefix needs to be reserved for use
with variables which are functionally internal to phplib, but because
they're being put under php4 session management, they have to be made
global, which puts them at risk of being duplicated in application space.

I did first consider using some simple variables, as in the patch suggestion
you posted, but went with something more complex so as to avoid, in as much
as possible, any conflict with application space varibles.

I don't see any problem with using simple global variables for this job as
long as the name space is clearly identified and documented so as to avoid
any such conflict.  If the API were to specify, for instance, that all
variable names starting with $PHPLIB_INTERNAL (to use another name) are
reserved, and that an application should never define such a variable, the
problem of namespace conflicts would be effectively resolved.

This isn't to say that someone _couldn't_ screw up and overwrite such a
variable in the global scope, but they would have been warned, and this is a
pretty easy rule to follow.  The solution isn't perfect, nor is it really
kosher from an OOP perspective, but from a practical point of view it's very
workable.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |