Objectification

[Sesquipedalian]

Refactors SMF to use the object oriented code paradigm.

[jdarwood007]

I think the build job is failing because of this:

2023-11-04T20:56:41.2259237Z Could not locate SMF_SOFTWARE_YEAR

[frandominguezl]

Oh, this is awesome. I have no words!

I will look into this further, but this was pretty much needed and I'm glad that you had time to do this. Out of curiosity, for how long have you been working on this?

[Sesquipedalian]

Oh, this is awesome. I have no words!

Thanks! 😄

Out of curiosity, for how long have you been working on this?

Checks commit log...

Since Dec 22, 2022, at 20:21:21 UTC.

[jdarwood007]

( ! ) Fatal error: Uncaught Error: Typed static property SMF\Db\DatabaseApi::$db must not be accessed before initialization in /Sources/ErrorHandler.php on line 465
( ! ) Error: Typed static property SMF\Db\DatabaseApi::$db must not be accessed before initialization in //Sources/ErrorHandler.php on line 465
Call Stack
#	Time	Memory	Function	Location
1	0.0004	376416	{main}( )	.../index.php:0
2	0.0800	805696	SMF\Forum->__construct( )	.../index.php:130
3	0.0808	807496	SMF\Db\DatabaseApi::load( $options = ??? )	.../Forum.php:203
4	0.0884	873912	SMF\Db\APIs\MySQL->__construct( $options = [] )	.../DatabaseApi.php:360
5	0.0963	1020544	SMF\Db\APIs\MySQL->initiate( $user = '##########', $passwd = '######', $options = ['dont_select_db' => FALSE] )	.../MySQL.php:1917
6	0.0993	1027936	SMF\ErrorHandler::displayDbError( )	.../MySQL.php:1998

Looks like $db isn't there yet because of this:

		$class = __NAMESPACE__ . '\\APIs\\' . $class;
		self::$db = new $class($options);

Then when loading the database, we do so in the construct. Essentially we never can get a $db.

I debated if I should just fix this, but wanted to pass it through you, as its going to be a core issue and I'm still new to this code base. My idea was to have the API store the result of $class then have the Db hold a static error method which can call $db or if its not there, fall back to $class::error. Seems to fix it and provide a safe way to always just call Db::error and let it handle it.

[Sesquipedalian]

My idea was to have the API store the result of $class then have the Db hold a static error method which can call $db or if its not there, fall back to $class::error. Seems to fix it and provide a safe way to always just call Db::error and let it handle it.

I did something simpler:

$db_error = isset(Db::$db) ? @Db::$db->error() : '';

[Sesquipedalian]

I'm going to go ahead and merge this monster now. Bug fixes for any of it can be added in later PRs.

[jdarwood007]

My idea was to have the API store the result of $class then have the Db hold a static error method which can call $db or if its not there, fall back to $class::error. Seems to fix it and provide a safe way to always just call Db::error and let it handle it.

I did something simpler:

$db_error = isset(Db::$db) ? @Db::$db->error() : '';

Only issue with that is now we have no error information. It should be possible to get the error info, even from a failed connection.

[Sesquipedalian]

Good point. Feel free to submit a PR. 🙂

[shmax]

Bravo, sir. This was long overdue!