htmlpurifier
htmlpurifier copied to clipboard
ezyang
Would you please change htmlpurifier to PSR 4 autoloader style?
Hello @netroby, I must profess complete ignorance with regards to this issue. What is PSR 4 autoloader style? How do I change HTML Purifier to it? Are there backwards compatibility concerns?
This may be difficult if @ezyang wants to maintain compatibility with PHP 5.2. PSR-4 relies on namespaces, which weren't introduced until PHP 5.3.
@ezyang Because PHP 5.3 is no longer actively supported, would you consider making the change to PSR-4?
sorry for posting on closed issue, but I think it's important.
The oldies supported PHP version (for security fixes only) is 7.4: https://www.php.net/supported-versions.php
How about dropping supporting old PHP versions and only support a new ones (7.4+)? Will you approve such PR?
This way the package can support PSR-4.
This package created for security reasons, but on other hand it's not secure to support unsupported PHP version, as package maintainers, we should force devs to use new PHP versions (however it also has a downside that I'm aware of).
I guess no anyone want to use php any more, this issue open by me in 2015 year. then 8 year past.(or 7) Things changes a lot.
What's the motivation for psr-4? To me it just unnecessarily introduces a huge BC break, is a lot of work to change and has minimal benefit.
As for bumping PHP versions, it's largely unnecessary unless there is good reason. Pretty much everything can be done in PHP 5.3.
Yes, just to clarify: I'm OK to drop PHP support, but I'm NOT ok with egregious BC break.
@ezyang
Yes, just to clarify: I'm OK to drop PHP support, but I'm NOT ok with egregious BC break.
Does it mean we can use PSR 4 (means use \Ezyang\HTMLPurifier namespace instead \HTMLPurifier)?
I can create a PR that will:
- drop unsupported PHP version support
- use a new PSR 4 namespace
- use latest PHP version functionality (upgrade using https://github.com/rectorphp/rector)
I can optionally implement only 1 and 2 steps if you want to have as less changes as possible
@bytestream this packages uses class prefixes to avoid conflicts with other classes from other packages or project's classes. This is an approach used before 5.3.0, where namespaces where introduced. More reasons why PSR-4 introduced you can find here: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-meta.md
Another point, more subjective, modern PHP devs used to use PSR-4 and nowadays it looks weird to import long classnames with underscores and prefixes (but again, it's subjective [developers likes consistency, right?]).
Replacing everything to use namespaces would be a major BC break, so if that's something that is going to happen it might as well be linked with a major library change - I don't keep massively up to date with what's happening with this library but I don't believe one of those is in progress (?)
Yes, all modern PHP code should use namespaces but updating old code to use namespaces if you aren't doing any other work to that code is a bit much, especially for all the consumers of this library.
If you want to have that PSR-4 style syntax of HTMLPurifier in your code then just do use HTMLPurifier_ClassName as ClassName at the top of your file.
EDIT Though there is a BC compatible way, which is to add class_alias(NewClassName, OldClassName). Still, what's the value if you're not doing a major round of updates anyway?
@bytestream this packages uses class prefixes to avoid conflicts with other classes from other packages or project's classes. This is an approach used before 5.3.0, where namespaces where introduced. More reasons why PSR-4 introduced you can find here: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-meta.md
Another point, more subjective, modern PHP devs used to use PSR-4 and nowadays it looks weird to import long classnames with underscores and prefixes (but again, it's subjective [developers likes consistency, right?]).
Thanks. I'm aware of what PSR-0 and PSR-4 are. In my opinion, the arguments above don't provide sufficient justification to warrant such a huge BC break. My view is that it's a lot of work for someone to implement, a lot of work for end users / plugin developers and achieves absolutely nothing except compliance with a newer PSR standard.
A change like this does not have to be a BC break.
Class aliases can be used to ensure previous names are still working. This was done in twig 2.
See: https://github.com/twigphp/Twig/blob/872646a70ff83b3628d50c9bafa117af9f1da59e/src/Environment.php#L994
