The time flies really fast! Exactly 2 years ago I was the one and only user of this instance and now there are thousands of us! So happy birthday to Lemmings.world and hope you all enjoy our small corner of the internet!

cross-posted from: https://chrastecky.dev/post/16

Starting with PHP 8.5, you'll be able to do the following:

 public function __construct(
    final public string $someProperty,
) {}

This wasn't possible before, as promoted properties couldn't be declared final.

Perhaps the more interesting part is that you can now omit the visibility modifier if you include final. In that case, the property will default to public:

 public function __construct(
    final string $someProperty, // this property will be public
) {}

Personally, I’m not a fan of this behavior — I prefer explicit over implicit. Fortunately, it can be enforced by third-party tools like code style fixers. Still, I would have preferred if the core required the visibility to be specified.

What do you think? Do you like this change, or would you have preferred a stricter approach?

cross-posted from: https://chrastecky.dev/post/13

This change is quite straightforward, so this won’t be a long article. PHP 8.5 adds support for annotating non-class, compile-time constants with attributes. Compile-time constants are those defined using the const keyword, not the define() function.

Attributes can now include Attribute::TARGET_CONSTANT among their valid targets. Additionally, as the name suggests, Attribute::TARGET_ALL now includes constants as well. The ReflectionConstant class has been updated with a new method, getAttributes(), to support retrieving these annotations.

One particularly useful aspect of this change is that the built-in #[Deprecated] attribute can now be applied to compile-time constants.

As promised, this was a short post, since the change is relatively simple. See you next time—hopefully with a more exciting new feature in PHP 8.5!

cross-posted from: https://chrastecky.dev/post/15

PHP has long had a levenshtein() function, but it comes with a significant limitation: it doesn’t support UTF-8.

If you’re not familiar with the Levenshtein distance, it’s a way to measure how different two strings are — by counting the minimum number of single-character edits (insertions, deletions, or substitutions) required to change one string into another.

For example, the following code returns 2 instead of the correct result, 1:

var_dump(levenshtein('göthe', 'gothe'));

There are workarounds — such as using a pure PHP implementation or converting strings to a custom single-byte encoding — but they come with downsides, like slower performance or non-standard behavior.

With the new grapheme_levenshtein() function in PHP 8.5, the code above now correctly returns 1.

Grapheme-Based Comparison

What makes this new function especially powerful is that it operates on graphemes, not bytes or code points. For instance, the character é (accented 'e') can be represented in two ways: as a single code point (U+00E9) or as a combination of the letter e (U+0065) and a combining accent (U+0301). In PHP, you can write these as:

$string1 = "\u{00e9}";
$string2 = "\u{0065}\u{0301}";

Even though these strings are technically different at the byte level, they represent the same grapheme. The new grapheme_levenshtein() function correctly recognizes this and returns 0 — meaning no difference.

This is particularly useful when working with complex scripts such as Japanese, Chinese, or Korean, where grapheme clusters play a bigger role than in Latin or Cyrillic alphabets.

Just for fun: what do you think the original levenshtein() function will return for the example above?

var_dump(levenshtein("\u{0065}\u{0301}", "\u{00e9}"));

test

You know how in the previous post I urged everyone to do proper backups? Well, guess what happened... If you use https://schedule.lemmings.world/ as your scheduler, all your posts were deleted, including recurring ones etc. Sorry for the inconvenience.

I've merged a significant rewrite into the main branch and will be releasing it soon.

Before I do so, I want to let everyone know that this will be a major release which means some old functionality will be left behind and some new is coming and you should take care when upgrading.

Namely, backup the volumes you have bound for runtime cache and uploaded files. Those are bound to these container directories:

• /opt/runtime-cache
• /opt/uploaded-files

The database format has changed completely and is incompatible with the old version, after you upgrade to the (soon-to-be-released) version 2, you won't be able to come back to any previous version. For that reason, the only way to downgrade in case of migration failure is by using the aforementioned backup.

I've tested it a lot and the migration works well, but there's always the possibility that your instance has some weird edge case I didn't think of.

On the off chance you used the serverless deployment to AWS, it's now unsupported and Docker (or manual deploy) are the only supported options now. To migrate from Dynamo DB cache backend, I've added a app:migrate-dynamo command you can use.

The reason for this rewrite is simple, back when this project started, only very simple use-cases were supported and using a cache instead of DB was fine, but now I've basically implemented a few relational database features into a key-value cache storage and then I thought "Hey, you know what else has relational database features? Relational databases!" so here we go.

Pretty much nothing else has changed (except some general modernization and a few unrelated bug fixes), but this will make it possible to implement new features without losing my sanity.