php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #72285 SessionHandlerInterface Function Signatures
Submitted: 2016-05-30 00:24 UTC Modified: 2021-08-30 16:46 UTC
Votes:7
Avg. Score:3.6 ± 1.7
Reproduced:5 of 6 (83.3%)
Same Version:3 (60.0%)
Same OS:1 (20.0%)
From: hpdl at oscommerce dot com Assigned: cmb (profile)
Status: Closed Package: Session related
PHP Version: 7.0.7 OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: hpdl at oscommerce dot com
New email:
PHP Version: OS:

 

 [2016-05-30 00:24 UTC] hpdl at oscommerce dot com
Description:
------------
The documentation for the following functions include parameter type declarations:

SessionHandler::open(string $save_path, string $session_name)
SessionHandler::read(string $session_id)
SessionHandler::write(string $session_id, string $session_data)
SessionHandler::destroy(string $session_id)
SessionHandler::gc(int $maxlifetime)

http://php.net/manual/en/class.sessionhandler.php

however using the same type declarations in the session handler class returns a PHP fatal error.

Also tested with PHP 7.1.0-dev rc3495d5 with the same result.

Test script:
---------------
<?php
class SessionTest implements \SessionHandlerInterface
{
    public function __construct()
    {
        session_set_save_handler($this, true);
    }

    public function open(string $save_path, string $name): bool
    {
        return true;
    }

    public function close(): bool
    {
        return true;
    }

    public function read(string $session_id): string
    {
        return '';
    }

    public function write(string $session_id, string $session_data): bool
    {
        return true;
    }

    public function destroy(string $session_id): bool
    {
        return true;
    }

    public function gc(int $maxlifetime): bool
    {
        return true;
    }
}

$SessionTest = new SessionTest();


Expected result:
----------------
No error should be expected.

Actual result:
--------------
Fatal error: Declaration of SessionTest::open(string $save_path, string $name): bool must be compatible with SessionHandlerInterface::open($save_path, $session_name) in C:\SessionTest.php on line 2

Fatal error: Declaration of SessionTest::read(string $session_id): string must be compatible with SessionHandlerInterface::read($key) in C:\SessionTest.php on line 2

Fatal error: Declaration of SessionTest::write(string $session_id, string $session_data): bool must be compatible with SessionHandlerInterface::write($key, $val) in C:\SessionTest.php on line 2

Fatal error: Declaration of SessionTest::destroy(string $session_id): bool must be compatible with SessionHandlerInterface::destroy($key) in C:\SessionTest.php on line 2

Fatal error: Declaration of SessionTest::gc(int $maxlifetime): bool must be compatible with SessionHandlerInterface::gc($maxlifetime) in C:\SessionTest.php on line 2

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-05-30 05:29 UTC] krakjoe@php.net
-Type: Feature/Change Request +Type: Documentation Problem
 [2016-05-30 05:29 UTC] krakjoe@php.net
This is not a problem particular to this interface; Many such documentation pages are not in sync with the code.

The problem is we can't change the code without breaking BC, so I think this is a documentation problem.

I think we should make effort to inform people that prototypes in documentation don't always match code, and that it's code (reflection) that you need to look at if you are extending internal classes.
 [2016-05-30 09:31 UTC] yohgaki@php.net
-Type: Documentation Problem +Type: Bug -Assigned To: +Assigned To: yohgaki
 [2016-05-30 09:31 UTC] yohgaki@php.net
Object API in session is the main source of session module problems...
 [2016-05-30 09:34 UTC] yohgaki@php.net
-Type: Bug +Type: Feature/Change Request -Operating System: WIN10 +Operating System: *
 [2016-05-30 09:34 UTC] yohgaki@php.net
Change Request would be the suitable bug type.
 [2016-05-30 11:05 UTC] bwoebi@php.net
Perhaps we just could specify types on internal (non-final) classes and interfaces function parameters.

Then we can argument with covariance if someone leaves the scalar types out (=> no BC break) and it still works when people use the scalar types.
 [2020-12-09 15:27 UTC] cmb@php.net
> Then we can argument with covariance if someone leaves the
> scalar types out (=> no BC break) and it still works when people
> use the scalar types.

For the record, this is basically done for PHP 8: scalar parameter
types are specified relying on contravariance to not break BC.
Scalar return types are not specified, again for BC reasons.
 [2021-08-30 16:46 UTC] cmb@php.net
-Status: Assigned +Status: Closed -Assigned To: yohgaki +Assigned To: cmb
 [2021-08-30 16:46 UTC] cmb@php.net
Anyhow, this is basically solved as of PHP 8.0.0[1], and further
improved as of PHP 8.1.0[2].

[1] <https://3v4l.org/7rrtb>
[2] <https://3v4l.org/7rrtb/rfc#vgit.master>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 10:01:29 2024 UTC