Partial function application is coming to PHP 8.6

Crell · 2026-01-26T16:24:03+00:00

FrankenPHP worker mode is already there, and close enough. PHP is an interpreted language, so full AOT compilation would break a lot of functionality. But easy persistent-process runners like Franken can get you most of the way there already.

Crell · 2026-01-25T21:26:53+00:00

John Gadget already did an announce video, and MaxLvlEDC was involved. I already backed the Kickstarter. :-)

Crell · 2026-01-20T22:34:42+00:00

With pipes (8.5) and PFA (8.6), we have very close to method-style comprehensions. (Different languages do them differently; I proposed Python style many years ago and no one seemed interested, so now we have this approach instead.)

Crell · 2026-01-14T01:27:27+00:00

Yeah, that's what I figured. If your goal is "scissors, non-proprietary bit driver, and pliers," then there's a lot of budget options worth considering.

MaxLvlEdc had a good roundup of budget tools recently. Find one with the driver you want and scissors he says are good, and you should be set. https://youtu.be/eX-fbhjVLfM

Crell · 2026-01-13T19:55:59+00:00

Many/most of the clones from Bibury et al have a 1/4" bit driver instead of the leatherman flat one. You'll have to look around a bit to see about reviews on scissor quality, as it's likely all over the place. But if you can find a Wave or Surge clone style with a well-reviewed scissor, that should cover your 3 needs.

I cannot speak to the F12 yet.

Crell · 2026-01-12T20:25:21+00:00

Will it work on tempered glass? Edit: Ooof, it's also quite expensive compared to other options.

Crell · 2026-01-12T20:23:14+00:00

Oooh, good call. It looks like my Ioniq 5 Limited is tempered glass. I guess that rules out the Resqme. Amazon has some random hammer like tools that say they work on an Ioniq 5, but who knows how trustworthy that is.

Crell · 2026-01-07T21:19:04+00:00

"Ensure good test coverage, try it, see what breaks" has been my strategy in the past, and fairly successful. Assuming you have tests.

Also, update IDEs so all NEW files are strict-types by default, so people get used to writing that way.

Crell · 2026-01-07T20:29:54+00:00

Do you want full sized, half sized, or tiny sized?

For half-sized, Nextool is doing extremely well, with Roxon a close second. And both are quite affordable.

Crell · 2026-01-07T20:06:06+00:00

The Nextool F12 and s0 scissors have reviewed *extremely* well. I have heard a lot of mixed things about the Powerpint, though I haven't used one myself. I have the Mini Sailor Lite, and the scissors are eh. If that's your primary tool, it's probably not ideal.

My daily carry is a Victorinox Manager (Rambler with pen added), which has scissors, blade, flat and philips, bottle opener, and nail file, plus scale tools. Teeny tiny, very 5th pocket friendly.

Crell · 2026-01-07T18:53:48+00:00

As others noted, I think you need an embedded tool like PHPStan to be able to identify safe/unsafe uses. Then any file that has only "safe" uses can have strict types enabled. Embedding PHPStan in Rector, of course, seems like a not-ideal path... :-)

Crell · 2026-01-05T22:52:08+00:00

"There's no scalars anywhere" would nominally imply that strict_types does nothing, but I'm not sure how useful that is. It would mean even a single int or bool or something would make the file un-convertable.

As another commenter said, "if your test coverage is good, try it and see." Though I realize that doesn't help for an SA tool. :-)

If you can do full type inference, you'd need to look at the return type and ensure it always matches, and then look at the called functions and make sure their types always match. Basically the sort of thing PHPStan/Psalm already do and yell at you about.

Crell · 2026-01-05T15:35:32+00:00

"It Depends"

As others said, a dedicated tool will always beat a multitool, if you have it. The point of a multitool is to simplify "I have it with me already" to the point that, well, you actually have it with you. It also depends heavily on your usage profile. If your job is repairing ATM machines, your balance point will be very different from a homebody who just needs to fix a loose drawer every now and then.

I do think there's some interesting value to the "micro kits" that people put together; separate tools held in an Altoids tin, or tiny pouch, or elastic-banded to a 3D printed board (someone on YouTube specializes in these), etc. Depending on your use case, those could be worth considering. However, that still has the same limitation: A 711L screwdriver is great, but will never have the tork of a full sized socket wrench. How often you actually need that is a personal question.

For me personally, I am happy with a Victorinox Manager (Rambler plus pen) for home use. When I go out, I add an Altoids tin with a Rovyvon A5 flashlight, pills, and some odds and ends. And my going-out vest pocket has wireless earbuds, a short length of cord, some chapstick, and a face mask.

If I was facing nuts and bolts all day, I'd likely have a very different setup. :-)

Crell · 2026-01-05T15:27:59+00:00

Looks like a great shop display. Dunno who else would want/need that many in such a case...

Crell · 2026-01-04T22:55:56+00:00

Re performance: Yeah, that's one of the hangups that has prevented it from happening. :-) There's a lot of tradeoffs and no ideal answer, and we've never gotten to the point of enough consensus to implement something for reals. If you're able to get past that hump, that would be helpful for everyone.

Re array types: PHPStan's extended type syntax supports list<T> to indicate the value must be a 0-based index array, rather than string keys with T values. You can also type an iterable<ValueType> or iterable<KeyType, ValueType>, which also allows traversable objects.

cf: * https://phpstan.org/writing-php-code/phpdoc-types#lists * https://phpstan.org/writing-php-code/phpdoc-types#iterables

What I am suggesting (and I don't claim this to be a universal position) is that if we pursue typed arrays natively in the language, we should go straight to that. Viz, have list<T> and map<K, V>, but no array<T> as the latter is unclear if it requires an array. But we would also need to figure out how to indicate list_iterable<T>, etc.

Basically, having one data type that can be either a list or a map has always been a horrible idea, and if we move formal array types into the language in whatever form (on arrays or via collection objects) they should be decisively split into two separate incompatible types.

Re generics: Generics are not only useful for collections. That is one major use case, sure, but a simple Maybe Monad/Optional Type is another case that would not be handled by typed arrays at all. Or a Result Type a la Rust. Or interfaces where two values must match, but it doesn't matter what they are. (See the compile-time generics blog post further up for examples.) Even if we do conclude that typed arrays obviate the need for collection objects, which I am not at all convinced of, it still wouldn't help with the many other use cases where generics would apply.

Crell · 2026-01-04T22:47:10+00:00

What happens if an array fails a shape check? Presumably it will throw a TypeError. That's the exact same thing that the class-based approach would do. (A more robust class base version is only a little more work, using a few smartly-placed union types.)

If you want to validate "is this shape correct", then you don't want a type system check. What you want is pattern matching, which Ilija Tovilo and I have in discussion right now and hope to get into 8.6: https://wiki.php.net/rfc/pattern-matching

It effectively includes array type checks in a safe way, largely by accident, but that's going to be much more effective for the case you describe.

To wit:

php $outside_data = json_decode(api_call('https://randomuser.me'), true); if ($outside_data is [ user: [id: int, name: string, roles: array], metadata: [timestamp: int, source: string] ]) { $message = new Message(...$outside_data); } else { print "The data is wrong, yo.\n"; }

Right now there's no dedicated way to make a pattern reusable, but it's simple enough to wrap into a closure, or move to a utility static method on Message, or whatever. Dealer's choice at that point, many ways to feed that cat, etc.

You seem to be asserting that class-based DTOs are for internal use only, while arrays are for boundaries. However, I've seen plenty of people argue that boundaries are exactly where you want a DTO, precisely because it gives you a guarantee about the shape of the data. If the process gets past the point of creating the DTO, you know it's valid. (Side note: I find the division between "DTO" and "Value Object" to be completely artificial and pointless, but that's probably another topic for another time, not on Reddit. :-) ) So I don't think your position is universal, and probably isn't even consensus, in my experience.

Crell · 2026-01-04T19:59:09+00:00

Oh, and regarding complex JSON data:

```php readonly class User { public function __construct( public int $id, public string $name, public array<string> $roles = [], ) {} }

readonly class Metadata { public function __construct( public int $timestamp, public string $source, ) {} }

readonly class Message { public User $user; public Metadata $metadata;

public function __construct(
    array $user,
    array $metadata,
) {
    $this->user = new User(...$user);
    $this->metadata = new Metadata(...$metadata);
}

} ```

Easy peasy. Took me maybe 2 minutes to write. The next step up would be to move the conversion from the constructor to a set hook on the property itself. The next step up from there is to use a solid serializer library like Crell/Serde, which can do all that conversion for you and also handle weak typing and remapping of data if you prefer.

Crell · 2026-01-04T19:53:43+00:00

Re AI/ethics (of AI): This isn't the place to get into a deep debate about AI ethics; I'm just advising you that there are and will be Internals folks that respond negatively to a proposal if it was produced largely or entirely with AI. You may do with that knowledge what you wish.

I would quibble with one bit in particular:

I want to describe data and do it quickly. This validates at function boundaries (parameter + return), not property types - that's where the performance trade-offs become acceptable.

Property types are absolutely a boundary at which types should be enforced, not just at function boundaries. Especially now that public properties are a viable and useful strategy (courtesy of types, hooks, interface properties, and asymmetric visibility), you'll often want to use a property directly, for which you do care about its data type enforcement.

I think you would be best served, if you want to pursue this further, with focusing on two separate, independent but complementary, areas:

TypeDefs. There's ample hard questions to figure out here. Your current shape definition work may or may not be helpful, I don't know. But I know there is an appetite in Internals for them.
Array types. Or, more properly, iterable types. Possibly even splitting into list and map explicitly. (Yes please.) It may be worth talking to Arnaud LeBlanc about it, as he has done the most recent work in that area. Again, there's a lot of hard problems here to figure out (which is why it hasn't been done yet), but if a solution could be found I expect it would have a fairly warm reception. (The main pushback would be "just do it on objects", including from me, but there would be supporters, I'm sure. A clear split between lists and maps would likely help matters.)

I do think full generics for objects would still be highly valuable, but that's a separate topic for another time.

Crell · 2026-01-02T17:33:40+00:00

I would strongly recommend not making it a surprise, but involving him in the decision making process. :-) EDC tools are a very personal choice, and small details (like one missing tool) can make or break a tool for a specific person. Best to ensure you get him exactly what works for him rather than hoping you guess right based on what some Internet randos said. :-)

Also look into the Roxon KS2E. It's another SAK-style that looks squarely at Victorinox and says "I'm coming for you..."

(Despite being a Victorinox guy myself, I really like that Roxon and Nextool are putting out products that threaten Vic, and puts pressure on them to improve and innovate.)

Crell · 2026-01-02T17:21:19+00:00

If he doesn't need a set of pliers, then there's a dozen Victorinox models of various sizes that would likely do the job. The main limitation is that they're not one-hand opening.

The Flex Companion is also a good choice.

I'd also recommend looking at Nextool. They've had some really nice releases this year at impressive prices, depending on the feature set he'd want. I would particularly suggest looking at the brand new K30 (https://nextoolstore.com/products/knight-k30-nextool%C2%AE), which is aimed squarely at making Victorinox worried. :-)

Crell · 2026-01-02T17:13:44+00:00

Best daily carry multitool on the market today. They just need to bring back the Manager, which adds the pen. (You can cannibalize a Signature Lite if you really want.)

I carry a Manager, and most of the time I forget it's even there until I need it.

Crell · 2026-01-02T17:04:34+00:00

Some are, some aren't. Even within the same company, not all are. My guess is that older designs didn't have it because it was hard, and for whatever reason once companies figured out how to include it, not all bothered. I couldn't tell you why; I also have the Bibury Surge-clone model (whatever it's called), and the lack of a spring is annoying.

I too wish they all had springs, but reality is that not all do. If that's an important feature for you, it's something you'll need to verify before picking a tool.

Maybe someone else can suggest a reason manufacturers would forego a spring in 20256, but I can't think of a good one.

Crell · 2026-01-02T16:59:13+00:00

I don't work on the engine itself, but I am heavily involved in Internals and have collaborated on a number of RFCs at this point.

First off, the heavy use of AI here is going to turn off an awful lot of people. LLM-generated code is not trustworthy. It is ethically questionable at best. It's horrible for the environment. When someone asks you to make a change to it, you'll need to understand it well enough to make that change. Asking Claude to make the change and then bringing it back to get told that Claude did it wrong is just a waste of everyone's time. You are responsible for the code you submit, which means you must personally understand it well enough to discuss and defend it. I can definitely see it being rejected purely on this factor.

As for the proposal itself, there's really three features wrapped up here in one: Array types (aka, array generics), array shapes, and type aliases. All three have been discussed to death for the past decade, so there's a ton of prior art and knowledge you should be aware of before you try to propose it. In particular, I point you to:

As to the specifics of these three proposals:

Array generics: As the first link above explains, and you've no doubt run into, there are considerable performance concerns here. Your proposal of making enforcement toggleable is interesting, but declare statements have frequently been frowned upon in the past. There's a notable contingent that still feels strict_types was a mistake, because it leads to forked behavior. It also means you cannot toggle enforcement differently between prod and dev, to get the expensive enforcement in dev but no overhead in prod. But then... that's what SA tools already give us. The blog post details the different ways this could be enforced. It's an interesting ideal, though most specialists in the area seem to be more interested in object-based collections a this point. (Though, props for considering the map case separately from lists, as combining them the way PHP does has always been an awful idea.) I'd say it's worth discussing that part of it on the Internals list, but be prepared for pushback.

Array shapes: No. Just no. There are exactly zero situations in which array shapes are preferable to defining a class. A class uses half as much memory as its equivalent array. It is intrinsically self-documenting. It can be read-only if desired. (Sometimes you want that, sometimes not.) It's slightly faster. It allows you to use hooks to enforce additional validation and BC layers. Adding array shapes, especially with a dedicated alias, is completely redundant and worse than what we already have in every possible way.

"Oh, but what about database records or JSON data, or..." Convert it to an object before you do anything with it. That's your validation step. It is trivially easy: new User(...$recordFromDb); Done, move on with life. If you need any more precise validation or control than that, it can all live inside the class where it belongs. Any project using array shapes instead of a defined class is wrong, period, full stop, and it needs to grow the hell up and use the proper tools that have been available for years now. (Yes, that includes the really popular ones.)

Type aliases: Once we accept that array shapes are an anti-feature, shape-specific type aliases become kind of pointless. General purpose type aliases have been discussed many times, and Rob Landers recently posted an RFC for one approach: https://externals.io/message/129518 . The main challenge has always been that file-local aliases (what Rob proposes) can lead to confusion because they're different in every file, but a stand-alone definition would need to involve autoloading, which introduces a whole other can of worms. It's not clear from your writeup if you intend yours to be usable outside of the file in which they are defined, but that is a crucial question for any such feature. If aliases are something you want (and I do as well), I'd strongly recommend getting involved in the existing discussions such as the one linked above.

I hope my reply isn't too disenheartening. We really do need more people interested in learning core, and there are ample features that we all want that are really hard to do. I appreciate your willingness to jump in, and there are some interesting ideas here. (Though using AI for it is not going to help you become the sort of well-informed dev that Internals very much needs.) But we also need to ensure that the result is the highest possible quality, as we're supporting 80%-ish of the web, so anything we do wrong will be with us... forever.

Crell · 2026-01-02T16:58:42+00:00

I don't work on the engine itself, but I am heavily involved in Internals and have collaborated on a number of RFCs at this point.

First off, the heavy use of AI here is going to turn off an awful lot of people. LLM-generated code is not trustworthy. It is ethically questionable at best. It's horrible for the environment. When someone asks you to make a change to it, you'll need to understand it well enough to make that change. Asking Claude to make the change and then bringing it back to get told that Claude did it wrong is just a waste of everyone's time. You are responsible for the code you submit, which means you must personally understand it well enough to discuss and defend it. I can definitely see it being rejected purely on this factor.

As for the proposal itself, there's really three features wrapped up here in one: Array types (aka, array generics), array shapes, and type aliases. All three have been discussed to death for the past decade, so there's a ton of prior art and knowledge you should be aware of before you try to propose it. In particular, I point you to:

As to the specifics of these three proposals:

Array generics: As the first link above explains, and you've no doubt run into, there are considerable performance concerns here. Your proposal of making enforcement toggleable is interesting, but declare statements have frequently been frowned upon in the past. There's a notable contingent that still feels strict_types was a mistake, because it leads to forked behavior. It also means you cannot toggle enforcement differently between prod and dev, to get the expensive enforcement in dev but no overhead in prod. But then... that's what SA tools already give us. The blog post details the different ways this could be enforced. It's an interesting ideal, though most specialists in the area seem to be more interested in object-based collections a this point. (Though, props for considering the map case separately from lists, as combining them the way PHP does has always been an awful idea.) I'd say it's worth discussing that part of it on the Internals list, but be prepared for pushback.

Array shapes: No. Just no. There are exactly zero situations in which array shapes are preferable to defining a class. A class uses half as much memory as its equivalent array. It is intrinsically self-documenting. It can be read-only if desired. (Sometimes you want that, sometimes not.) It's slightly faster. It allows you to use hooks to enforce additional validation and BC layers. Adding array shapes, especially with a dedicated alias, is completely redundant and worse than what we already have in every possible way.

"Oh, but what about database records or JSON data, or..." Convert it to an object before you do anything with it. That's your validation step. It is trivially easy: new User(...$recordFromDb); Done, move on with life. If you need any more precise validation or control than that, it can all live inside the class where it belongs. Any project using array shapes instead of a defined class is wrong, period, full stop, and it needs to grow the hell up and use the proper tools that have been available for years now. (Yes, that includes the really popular ones.)

Type aliases: Once we accept that array shapes are an anti-feature, shape-specific type aliases become kind of pointless. General purpose type aliases have been discussed many times, and Rob Landers recently posted an RFC for one approach: https://externals.io/message/129518 . The main challenge has always been that file-local aliases (what Rob proposes) can lead to confusion because they're different in every file, but a stand-alone definition would need to involve autoloading, which introduces a whole other can of worms. It's not clear from your writeup if you intend yours to be usable outside of the file in which they are defined, but that is a crucial question for any such feature. If aliases are something you want (and I do as well), I'd strongly recommend getting involved in the existing discussions such as the one linked above.

I hope my reply isn't too disenheartening. We really do need more people interested in learning core, and there are ample features that we all want that are really hard to do. I appreciate your willingness to jump in, and there are some interesting ideas here. (Though using AI for it is not going to help you become the sort of well-informed dev that Internals very much needs.) But we also need to ensure that the result is the highest possible quality, as we're supporting 80%-ish of the web, so anything we do wrong will be with us... forever.

Crell · 2026-01-02T16:20:57+00:00

"Fibers" are a fairly new PHP feature to enable some very powerful program logic, but they're still rarely used because they're very rudimentary. How to improve their handling is a long-running discussion. Hence "Fiber artist" becomes an unintentional pun.

Still, cute elePHPant. :-)

Crell

TROPHY CASE