[endofreach]

Lol, what? Haven't heard of this... What's your experience with nativePHP?

While i am a defender of modern (!) php for web applications, this does sound rather weird. But also interesting. Thanks for the link.

I wonder though how "native" this is? Glancing over the docs it seems to be built upon tauri / electron? Not as native as i expected, but probably more native than most people would dare to think about...

[aarondf]

I haven't used it for anything, but it is developed by some friends of mine. It's certainly a novel approach! And they got it working on iOS too

[noduerme]

Lol indeed... I also still love PHP. For most small apps that's my go to backend, because who needs to worry about keeping Node running on some server you forgot about 2 years ago? And it's a fully modern language.

I'm delighted that there's some kind of desktop API here. On the one hand, the fact that it's talking with an Electron shell seems sort of magical. But it begs questions like, why wouldn't I just use a fully JS stack? And... since I've never created a graphical app in PHP before, would this be the right time to start?

[noduerme]

I'd also say ...patterns like this that return the object you modified in PHP weird me out, even though they're common in JS going back to JQuery:

>> Dialog::new() ->title('Select a file') ->open();

It's an interesting "modern"-ish design choice, but it doesn't feel very PHP-ish. $dialog = new Dialog('title') followed by $dialog->open() would feel more sane.

[9dev]

That heavily depends on the framework you use. Laravel uses call chains a lot, and with PHP 8.4 (or even 8.3?) you can chain on new:

  new Dialog()->title('Select a file')->open();

[noduerme]

Just from a high level, chains on 'new' are actually kind of awful. They're bad in a world like JS where lots of classes need to call async functions to spin up, but they're desperately worse in PHP where you really have to consider everything to be a blocking call. Something basic like this could easily hang a whole thread if, e.g. the title chose to read from a remote file. And it would be quite hard to tell what was hanging it. This is when it feels like PHP is getting out over its skis. I understand the desire to keep up with the Joneses, but there's no real penalty to writing your example in three lines rather than one. It's not really functional either way, and it's not especially debuggable either.

[9dev]

How would it make a difference if you split the statements up? A bad API is a bad API, and I’m pretty sure you can design one in any language (e.g. hide a while (true) within an innocuous method). The way to trace it down is the same in PHP as elsewhere, too—use a debugger. All that said, just don’t design shitty APIs and give your methods useful names.

An advantage of being able to chain calls are fluent expressions that you can return immediately, for example from arrow functions or match expressions, which definitely makes for easier to read code.

[noduerme]

I can't think of a lot of examples where I'd want to call:

new API()->object->method()->subResult

particularly if the API might block. But I can think of a lot of reasons I wouldn't want to see that in my codebase. Usually starting with the fact that

try {

$api = new API();

}

should have a catch after it.

For local stuff, fine, if you want to write that way. I don't find it eminently more readable than seeing a variable created and employed. And I'd like to see the line number the error was thrown on, if I'm reading error logs in production.

[duskwuff]

For what it's worth, blocking might not be an issue in the future. There's some discussion on the PHP mailing list about adding async capabilities to the language.