Skip to content
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

[core] refactor: introduce php autoloader #2508

Closed
wants to merge 13 commits into from
Closed

[core] refactor: introduce php autoloader #2508

wants to merge 13 commits into from

Conversation

dvikan
Copy link
Contributor

@dvikan dvikan commented Mar 18, 2022

One small step towards code base modernization.

This is a refactor that makes it easier to introduce an autoloader.

dvikan added 10 commits March 18, 2022 04:05
One small step towards adding an autoloader.
Moving file includes to a central location in lib/rssbridge.php
makes it easier to introduce an autoloader later.
They are completely empty.
This change fixes the problem with loading files
in the correct order.
Ideally these files should be located in some other dir.
There are a few requires in some bridges. But since they
are require_once, it is not a problem.
@dvikan
Copy link
Contributor Author

dvikan commented Mar 19, 2022

I think we are ready to introduce an autoloader now. Example:

spl_autoload_register(function ($class) {
	$folders = [
		__DIR__ . '/../actions/',
		__DIR__ . '/../bridges/',
		__DIR__ . '/../caches/',
		__DIR__ . '/../formats/',
		__DIR__ . '/../lib/',
	];
	foreach ($folders as $folder) {
		$file = $folder . $class . '.php';
		if (is_file($file)) {
			require $file;
		}
	}
});

Ping @f0086 @em92 @Bockiii @yamanq

@dvikan dvikan changed the title [core] refactor: improve includes organization [core] refactor: prepare for introduction of an autoloader Mar 19, 2022
@Bockiii
Copy link
Contributor

Bockiii commented Mar 19, 2022

Can you do a write up of what this will do? Like, the usecase behind it and then the general approach in prose?

Easier than to try to assess it from the code :)

@dvikan
Copy link
Contributor Author

dvikan commented Mar 20, 2022

Autoloading is the process of automatically loading PHP classes without explicitly loading them with the require(), require_once(), include(), or include_once() functions.

Advantages:

  • Code isn't littered with include calls
  • No need to worry about dependency ordering of includes
  • Easier to introduce php namespaces (and later PSR4)
  • Easier to reuse parts of the application when testing in cli
  • Easier to merge with composer's autoloader when we introduce it later
  • Enforcement of one class per file (no mixing of responsibilities)

One last one is that the code base looks kinda ancient and old. Which it is. From a marketing and popularity standpoint as a FOSS project, I think we should start to modernize. Will attract more contributors.

Comment on lines 2 to 11
require_once('GelbooruBridge.php');

class MspabooruBridge extends GelbooruBridge {

const MAINTAINER = 'mitsukarenai';
const NAME = 'Mspabooru';
const URI = 'http://mspabooru.com/';
const DESCRIPTION = 'Returns images from given page';
const PIDBYPAGE = 50;

Copy link
Contributor

Choose a reason for hiding this comment

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

Why we delete this bridge and some others?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah this is a mistake on my part. I though this was a dead and empty skeleton bridge. I can see now that it inherits from another bridge.

Comment on lines +3 to +6
/**
* This class is a monkey patch to 'extend' simplehtmldom to recognize <source>
* tags (HTML5) as self closing tag. This patch should be removed once
* simplehtmldom was fixed. This seems to be a issue with more tags:
Copy link
Contributor

Choose a reason for hiding this comment

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

Since simplehtmldom is abandoned, I am considering to make this patch directly in vendor/simplehtmldom directory or fork simplehtmldom in RSS-Bridge/simplehtmldom. What do you think about it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since it's abandoned I think moving it to vendor/simplehtmldom is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe later we can seriously consider maintaining a fork under the rss-bridge organization. We probably have to live with this dependency a long time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

New bridges in the future should maybe start using:
https://symfony.com/doc/current/components/css_selector.html

or any other modern DOM crawlers.

Copy link
Contributor

@logmanoriginal logmanoriginal Mar 21, 2022

Choose a reason for hiding this comment

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

If I remember correctly, this bug was addressed a long time ago. The monkey patch should no longer be necessary with the current version of simplehtmldom.

Comment on lines -30 to -31
require_once $filePath;

Copy link
Contributor

Choose a reason for hiding this comment

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

Tbh, I don't understand why should we not use require_once in this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This commit move the include calls to lib/ and later an autoloader is introduced so it's not necessary to manually include files anymore.

if($firstCall && file_exists(PATH_ROOT . 'DEBUG')) {
if($firstCall && file_exists(__DIR__ . '/../DEBUG')) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why can't we use PATH_ROOT here and on other places?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess this is mostly a matter of taste. I find the __DIR__ and __FILE__ more intuitive because they are file relative. Whereas the PATH_ROOT is unknown and must be looked up by new code reviewers.
In any case PATH_ROOT and __DIR__ . '/../' points to the same directory.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also when we migrate to composer's autoloader later (I hope!) we can't use PATH_ROOT in composer.json to define where our classfiles are located.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess this is mostly a matter of taste. I find the __DIR__ and __FILE__ more intuitive because they are file relative. Whereas the PATH_ROOT is unknown and must be looked up by new code reviewers. In any case PATH_ROOT and __DIR__ . '/../' points to the same directory.

Matter of taste is not a good reason for change. __DIR__ . '/../' does not tell you anything about the path, except its location. PATH_ROOT (as well as PATH_LIB, PATH_CACHE, etc.) were introduced to improve readability of the codebase by adding semantic information. Please also note that it is much easier to find all references of PATH_ROOT than it is to locate the right place in all variations of __DIR__ . '/../...'.

That said, this change is not needed for the autoloader and should be removed from this particular PR.

Also when we migrate to composer's autoloader later (I hope!) we can't use PATH_ROOT in composer.json to define where our classfiles are located.

This is fine. Once composer's autoloader is implemented, most of the paths will vanish from the codebase anyway.

Reert mistake on my part. These are actually real bridges.
I didn't notice that they extend other bridges.
This reverts commit ef54d4a.
@dvikan
Copy link
Contributor Author

dvikan commented Mar 22, 2022

Need more feedback regarding this change.

@Bockiii
Copy link
Contributor

Bockiii commented Mar 25, 2022

Did you check the monkey-patch-topic? logman said it may not be neccessary anymore.

Comment on lines 209 to +216
foreach (glob(PATH_LIB_BRIDGES . '*.php') as $path) {
$bridges[basename($path, '.php')] = array($path);
}

// Remove a few files that are not bridges
unset($bridges['PepperBridgeAbstract']);
unset($bridges['DanbooruBridge_Fix_Simple_Html_Dom']);

Copy link
Contributor

Choose a reason for hiding this comment

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

Bridges must have a Bridge suffix in their file name, so instead of removing unwanted files manually, perhaps this can be solved by applying the correct filter.

Suggested change
foreach (glob(PATH_LIB_BRIDGES . '*.php') as $path) {
$bridges[basename($path, '.php')] = array($path);
}
// Remove a few files that are not bridges
unset($bridges['PepperBridgeAbstract']);
unset($bridges['DanbooruBridge_Fix_Simple_Html_Dom']);
foreach (glob(PATH_LIB_BRIDGES . '*Bridge.php') as $path) {
$bridges[basename($path, '.php')] = array($path);
}

@dvikan dvikan changed the title [core] refactor: prepare for introduction of an autoloader [core] refactor: introduce php autoloader Apr 4, 2022
@Bockiii
Copy link
Contributor

Bockiii commented Apr 5, 2022

I think if you merge logmans suggestions, this can be given a go

@dvikan
Copy link
Contributor Author

dvikan commented Apr 7, 2022

I'll make a new smaller PR.

@dvikan dvikan closed this Apr 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants