Skip to content

ext/sqlite3: SQLite3::close, SQLite3Stmt::close and SQLite3Result::fi… #10878

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

devnexen
Copy link
Member

…nalize

changed from bool return value to void.

Copy link
Member

@Girgias Girgias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I agree in theory, but I worry there are people doing:

if ($db->close()) { ... }
else { ... }

will have the code logic completely changed. But then waiting for PHP 9 for this changes means we would need to change the return types again :/

UPGRADING Outdated
@@ -102,6 +102,10 @@ PHP 8.3 UPGRADE NOTES
argument is non empty with the class not having constructor.
. pg_insert now raises a ValueError instead of a WARNING when the table specified is invalid.

- Sqlite:
. SQLite3::close, SQLite3Result::finalize and SQLite3Stmt::close are void.
Previously, they returned bool.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Previously, they returned bool.
Previously, they always returned true.

Seems more accurate

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true

@@ -312,7 +312,7 @@ public function __construct(string $filename, int $flags = SQLITE3_OPEN_READWRIT
public function open(string $filename, int $flags = SQLITE3_OPEN_READWRITE | SQLITE3_OPEN_CREATE, string $encryptionKey = ""): void {}

/** @return bool */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment needs to be removed and I think also replaced with /** @tentative-return-type */

Is this correct @kocsismate ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking at another void function, you seem to be correct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you are right

@@ -436,5 +436,5 @@ public function fetchArray(int $mode = SQLITE3_BOTH): array|false {}
public function reset(): bool {}

/** @return bool */
public function finalize() {} // TODO make return type void
public function finalize(): void {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

…nalize

changed from bool return value to void.
@devnexen devnexen force-pushed the sqlite3_finalize_close_change branch from 66aae9d to ffb1a1f Compare March 21, 2023 18:16
@devnexen devnexen requested a review from kocsismate as a code owner March 21, 2023 18:16
@kocsismate
Copy link
Member

I'd love if the signatures in question could be fixed, but I'm also worried about the unsatisfactory upgrade path which I mentioned in a similar PR. I'm afraid we cannot silently change these signatures this fundamentally :( IMO at least there should be an RFC in order to provoke a discussion and in order to settle on a solution which the majority accepts.

@kocsismate kocsismate requested a review from iluuu1994 March 28, 2023 06:48
@iluuu1994
Copy link
Member

but I'm also worried about the unsatisfactory upgrade path
IMO at least there should be an RFC in order to provoke a discussion and in order to settle on a solution which the majority accepts.

I agree. The true return type doesn't affect normal usage of the API. Thus changing it might not be considered useful. Changing the return type from bool to true might offer similar benefits for static analysis (condition is always true error).

@devnexen
Copy link
Member Author

Those are fair points indeed.

@jorgsowa
Copy link
Contributor

jorgsowa commented Oct 9, 2023

Changing the return type from bool to true might offer similar benefits for static analysis (condition is always true error).

I agree. This path is more reasonable. It will not change the logic, but will encourage people to change the code what will allow to change the return type to void eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants