I think that your comments are a fair point, but given that
session_start() will create or open/restore a previous
session, affecting state of the script that's directly
related to session state, surely session_destroy() 
should do the converse, destroying the backend and also
the program state that session_start() introduced in the
first place. Incidentally, when session_end() is 
implemented, it should possibly also clear registered
variables, although that depends on whether you 
regard a closed session to still exist - which of
course it technically does. Just because it's not
actually open may not mean that values obtained from
that session aren't an accurate reflection of the
session, but the problem comes if you then change
variables associated with a closed session because
you then do have an incorrect view of session state.
Perhaps variables that are associated with a closed
session should then become 'const' or read only, and
modifying them should create at least a warning, because
this is likely to be symptomatic of a design flaw
in the users application - they're changing session state 
that isn't going to take effect.

Not all applications that call session_destroy() will
be ending at that point, in fact for mine, it's
merely beginning. If you link program state, which you
are doing via session_register(), to a session, I think
that this state should *always* accurately 
reflect the state of the session. Calling session_unset()
may be useful to reset an active session, but if there's
no session then there can be no data. 

In essence, once you've associated a variable to a session
entity, you should always be able to look to that variable 
to determine an accurate reflection of the session state.

- but perhaps we can agree to differ :-)

Nick

On Sun, Aug 05, 2001 at 06:34:22PM -0000, Bug Database wrote:
> ID: 12575
> Updated by: rasmus
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Analyzed
> Bug Type: Session related
> Operating System: Linux
> PHP Version: 4.0.6
> New Comment:
> 
> I think this is consistent behaviour.  session_start() brings data from your session 
>backend into your current script.  session_destroy() destroys the session data in 
>your session backend.  It does not and should not affect variables which are 
>currently active in your script.  The session_start() and session_unset() functions 
>are designed to affect the current active symbol table.


-- 
PHP Development 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]

Reply via email to