Where is highlight.php v10.x/v11.x?

[allejo]

For anyone curious and before anyone asks, highlight.php 10.x/11.x is planned and development will start in the coming weeks. I first need to finish off my semester and a few other commitments.

highlight.php 10 will require PHP 5.6+ (see #55)

The current estimated release of highlight.php v10/11 is Winter 2021

---

Why the delay?

highlight.js v10 introduced some breaking changes where grammars can no longer be represented by just JSON; grammars now support JS callbacks. While not many grammars are using this feature as of yet, I'm hesitant to dedicate myself to manually porting JS to PHP.

Does this mean highlight.php is dead?

No. Not at all. I do have some ideas for automatically translating JS to PHP to address this problem. I simply have not had time to work on this.

It's been over a year since this issue was created. Why haven't you done it yet?

I've had other projects, work, and school that have required my attention/focus/time. Feel free to sponsor me to work on this project 😄 ❤️

[joshgoebel]

Very curious to see how you handle the dynamism that's possible now.

[allejo]

Very curious to see how you handle the dynamism that's possible now.

Me too 😅

[joshgoebel]

I used it in the new SHEBANG mode too since now it's actually possible (for the first time) to check if a match starts at the beginning of the content, not just the beginning of the line.

[phpfui]

For version 10, can we change the HighlightUtilities namespace to Hightlight\Utilities and make Highlight\Utilities a static class with the functions as static methods? I think this is a better organization. No reason for two namespaces.

Also I think there should be a src directory to make the package a bit more standard.

Neither of these changes should really impact many users and it should be an easy change.

Happy to submit a PR with the above changes, I just don't like submitting PRs with changes such as this without buy in from the author. But V10 would be the time to make the change.

[allejo]

For version 10, can we change the HighlightUtilities namespace to Hightlight\Utilities and make Highlight\Utilities a static class with the functions as static methods? I think this is a better organization. No reason for two namespaces.

The only reason I opted to have a separate namespace was so we can keep the Highlight namespace as loyal as possible to a port of the highlight.js project. Let me sit on this one for a bit.

Is there an advantage to having these functions under a static class? As functions, you can currently import them like use function \HighlightUtilities\getStyleSheetFolder() and even give them aliases. This is a 5.6+ feature, so considering the min requirement of 5.6 for 10.x, this would continue to work.

Also I think there should be a src directory to make the package a bit more standard.

Neither of these changes should really impact many users and it should be an easy change.

Happy to submit a PR with the above changes, I just don't like submitting PRs with changes such as this without buy in from the author. But V10 would be the time to make the change.

Yea, I've been wanting to change this project into a PSR-4 setup for a while, just never got around to it. Sure you can make that PR, continue to keep two separate namespaces for now though for Highlight and HighlightUtilities.

[phpfui]

Actually after I wrote this, I realized you only need one namespace. You put in a class called Utilities with static methods. So instead of \HighlightUtilities\getStyleSheetFolder(), it becomes \Highlight\Utilities::getStyleSheetFolder().

It is a very easy port, just search and replace really and uses one namespace.

As for PSR-4, not sure it makes much of a difference vs PSR-0 if you put things in a src directory. The problem with PSR-0 and no source directory is that you can't programatically tell what belongs to the library and what is just support code. This may not matter to most users, but if you are using a super fast autoloader, then you need a mapping between the namespace and the file system, and you have no easy way to populate the file system without including a bunch of junk. Anyway, a src is best practice and does not really impact anything.

Let me know your thoughts on the Utilities class and static methods. I think it is the best approach.

Thanks thanks for responding. I use this package for my PHPFUI website to display the source and it works great, although sometimes a bit slow on larger files.

[phpfui]

So I started moving to PSR-4 and replacing the HighlightUtilities namespace. Turns out you just change \HightlightUtilities\ to \Highlight\Utilities:: and you are done!

But I noticed that the project is PHP 5.4 (barf!). How about PHP 7.1 or 7.2? 7.1 is no longer supported, but a decent version. 7.2 adds nullable types, which may not be needed. Leave V9 for older versions, and V10 would be 7.1 or higher.

Also would want to upgrade PHPUnit, which is fairly easy.

[allejo]

Before we get a bit too carried away...

I'm not really sold on the benefits of moving the HightlightUtilities namespace to an abstract class, \Highlight\Utilities. I really do not want to deviate too much from origin project (highlight.js) and clutter up the main Highlight namespace, which is why it was added as a separate one. What if highlight.js introduces a Utilities down the line? I want to make the separation of the components of this project clear, what is loyal to highlight.js, and what isn't.

As for the PHP version, v10 is currently planning on targeting 5.6; see the first post in this issue and issue #55. Since I'm actively working on a WordPress plugin that incorporates this library and there are no critical features that we need from PHP 7.x, I have no problems supporting 5.6 for a while longer. highlight.js is planning to have a quicker release schedule, so there'll be more opportunities to bump the minimum PHP version without having to wait for a major bump.

[phpfui]

It is your library. I am simply suggesting some common techniques that work well. Classes with static methods work better than functions in namespaces as it allows for a simpler autoloader. When you start getting into larger projects, autoloader speed becomes an issue. A PSR-0 autoloader is super fast. Well structured PSR-4 libraries can be converted to PSR-0 easily. My autoloader takes 0 bytes of memory and has extremely low computational overhead (no array lookups). But it does not work well with namespaced functions (looking at you GuzzleHttp).

I am not big fan of taking more namespaces than needed, and you really only need one. I did delete the Autoloader class, so as far as classes in the Highlighter namespace that are not in the JS version, it is a wash. It is easy enough to rename Utilities if it comes to that.

The alternative might be to do a static method class in HighlightUtilities, but then you start duplicating names (ie. \HightlightUtilities\Utilities::methodName).

The biggest improvement is the src file structure, That will work with PSR-0 or 4.

Also the current standard for PHP libraries (Laravel and PHPUnit for example) is to just support current versions of PHP (meaning 7.2 currently). This encourages people to continue to upgrade, which benefits the entire community. Typed method parameters, typed return values, type properties and nullable types all help to insure your code works as expected. Typeless languages are simply not as good as more strongly typed languages. There are reasons why languages have historically added more and more type checking as the language progresses. FORTRAN, C, PHP and even the lowly JavaScript have all added more type checking as they evolved. But 5.6 is better than 5.3 for sure.

Let me know what you want to do and happy to update the PR. My biggest things are a src directory and no namespaced functions. PHP 7.2 is just me trying to push the PHP community into the 1990s of computer language design. I personally plan to bump the minimum PHP requirements in all my PHP projects to only currently supported versions when PHP 8 ships. Keeping up with PHP releases provides huge speed improvements, and I have seen noticeable speed improvements when ever I upgrade PHP. YMMV.

And thanks for providing this library!

[localheinz]

@allejo

Is there anything we can do to support the upgrade?

Any help needed on the code, or perhaps some sponsoring?

[phpfui]

I am not sure what else is in 10, but happy to test tonight. I will see if I can update to dev-master for my http://www.phpfui.com site. Will be publicly viewable for many php files.

…

On Thu, Jun 3, 2021, 5:51 PM Andreas Möller ***@***.***> wrote: @allejo <https://github.com/allejo> Is there anything we can do to support the upgrade? Any help needed on the code, or perhaps some sponsoring? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#73 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYW6S5HVLZLP5473EJOAITTQ72N3ANCNFSM4MYJOBTA> .

[phpfui]

I upgraded phpfui.com to dev-master and WOW! It is much faster. The largest file timed out before (170K) and everything seems super snappy now. I would recommend an immediate release of V10. It was plug in compatible. I did not have to change anything.

Here are some example pages to check out. The second one did not load before:

• http://phpfui.com/?n=Highlight&c=Highlighter&p=f (proof of V10!)
• http://phpfui.com/?n=PhpParser%5CParser&c=Php7&p=f (170K)
• http://phpfui.com/?n=PhpParser&c=PrettyPrinterAbstract&p=f (60K)

You are looking at the actual code that is running on the site. The site renders the documentation real time, it is not stored, but generated on request.

Also, if you want to include a full class documentation link in the readme file, use this link: http://phpfui.com/?n=Highlight It includes all the namespaces, classes and readme. Since PHPFUI uses this package, it will always be documented on PHPFUI, as it always documents the classes it uses at a minimum (plus some other libraries like PhpParser, which is totally awesome).