Welcome to The PHP Foundation discussions!

[pronskiy]

🎉 Welcome to the PHP Foundation's official GitHub Discussions! 🎉

We're launching these experimental discussions as a direct response to the community's request for a more open and accessible platform for communication.

How is that different from php/php-src or Internals mailing list? Here you can share thoughts and insights without technical implementation unlike on php/php-src. It could be quicker and less formal compared to the mailing list. The ideas can also be not directly related to the source code.

⚠️ Note: This is an experiment. We may change things or shut it down completely. Please help us make it a better place for the PHP community.

Talk to you soon!
🐘💜

[AuroraYolo]

Hope to add asynchronous function

[pronskiy]

Are you already using ReactPHP/AmPHP/Swoole?

[AuroraYolo]

I used swoole a few years ago and am now learning swow. But I hope PHP will come up with an asynchronous function officially.

[leocavalcante]

Maybe a PSR for async functionality then tools like Swoole, React and Amp implement those interfaces.

[pl1998]

swoole's hyperf framework works with asynchronous and microservice architectures
https://hyperf.wiki/3.1/#/en/

[IgorDePaula]

A little over a year ago I made a suggestion for a new php function and didn't receive any response. What happened?

[pronskiy]

Could you link to where you made that suggestion please?

[IgorDePaula]

@pronskiy I sent my suggest to internals@lists.php.net, on dec, 27 / 2022.

[jrfnl]

Not a fan of yet another platform to "follow", especially as this is a organisation level discussion forum which does not allow for selectively "watching" what's going on (as far as I know). I.e. one would have to remember to manually check the forum once in a while or would need to "follow" the complete organisation, without being able to filter out everything else.

[pronskiy]

What do you currently use? I'm assuming ML and phpc mastodon?

[jrfnl]

Indeed.

[Crell]

FWIW, I really hate Discourse as a user.

[derickr]

I'm with Juliette here.

[jgarcianewemage]

open an MSN Group 😄

[sunnyphp]

Still waiting for generics.
Of course, you can use tools like Psalm, but this is not the same as native language tools.
I still don’t understand why they weren't implemented.

[pronskiy]

What exactly do you mean by "native language tools" here? What is it that you're missing with PHPStan/Psalm?

You can get explanations of why they haven't been implemented here:

• Generics experimentation (squashed) arnaud-lb/php-src#4
• Implementation notes PHPGenerics/php-generics-rfc#45

[sunnyphp]

Sorry, I mean "native language syntax support".

We can use Psalm PHPDoc annotations:

/**
 * @template T
 */
final class Collection
{
	/**
	 * @var array<int, T>
	 */
	public array $collection;

	/**
	 * @param array<int, T> $collection
	 */
	public function __construct(array $collection)
	{
		$this->collection = $collection;
	}

	/**
	 * @return T|null
	 */
	public function getFirst(): mixed
	{
		return $this->collection ? array_shift($this->collection) : null;
	}

	/**
	 * @return T[]
	 */
	public function getAll(): array
	{
		return $this->collection;
	}
}

But it's not same as native language syntax (the way I'd like to see it):

final class Collection
{
	public function __construct(private array of T $collection) {}

	public function getFirst(): T | null
	{
		return $this->collection ? array_shift($this->collection) : null;
	}

	public function getAll(): array of T
	{
		return $this->collection;
	}
}

Looks cleaner, simpler, clearer, right?

Essentially, the language lacks built-in support for strict typing in collections.

Thanks for links.

[pronskiy]

Gotcha.
Well, there are many open questions to follow up.

If it's only about collections, then it's possible to have generic collections without introducing generic generic syntax haha. @derickr and @Crell have given thought to this already.

Another question is whether that could be erased, i.e. syntax-only, generics? If we consider that option, I personally would like them to be in attributes instead https://github.com/php-static-analysis/attributes (/cc @carlos-granados) and have an official spec, as in recognised and described on php.net. That would give more flexibility in updating them while not introducing inconsistency to the language.

[Crell]

Almost no one is against generics in concept. I've done some research into how some of the edge cases should work, based on other languages, that can inform any eventual implementation. The challenge has always been that it's just really hard to do, given the nature of the PHP engine and the fact that it's a runtime environment with no global-scan ability at compile time. If a way can be found to actually do it properly, I am quite confident it would pass easily. But that's currently a very big IF.

[KorvinSzanto]

In my opinion the current status quo of writing annotations is superior to attributes . The main reason why is attributes can't go everywhere an annotation can, an additional reason is writing types in plain strings is a brutal workflow.

In my opinion generic type checking is a serious enough problem that a language level blessed solution must exist. Psalm and PHPStan are great but they don't agree 100% on what types do exactly and they still struggle to support edge cases without the performance losses you get writing something like this in PHP.

[AuroraYolo]

arnaud-lb/php-src#4 Are you still updating?

[kanyxmo]

When will a new PHP Plus programming language version 1.0 be launched, similar to the Go language, but still object-oriented with built-in coroutines. So, the spring of PHP will come again

[pronskiy]

@KorvinSzanto, can you name at least one other company that uses Hack except Facebook and Slack?

For a long time already, Hack is not providing any releases whatsoever; it's basically an internal project for Facebook/Meta.

[KorvinSzanto]

Just to be clear I don't use Hack and never have so I don't have any insider knowledge about this beyond what's publicly available.

can you name at least one other company that uses Hack except Facebook and Slack?

Their faq also lists Quizlet. I wouldn't be surprised if there are many more closed source companies and products using it as well.

To me this is a red herring though. Consider how much Facebook alone helped the PHP ecosystem just by forking with things like the PHP spec and massive performance improvements we saw in v7 and v8. Imagine how much more they could help the ecosystem if they didn't fork and instead put their 50 commits / week into PHP.
Of course Facebook remaining on PHP wouldn't have happened without some major negative changes to the PHP ecosystem so I wouldn't necessarily say that was the better option, but certainly the best option would be if Facebook and Slack were investing in PHP and not in Hacklang, and that could only possibly happen if PHP supported the features that these businesses require like first class async, generics, single binary support, etc.

For a long time already, Hack is not providing any releases whatsoever

You're right to say they haven't been tagging releases, that's very different than not providing any release. HHVM and by extension hack are both still fully open source and get many commits a day: https://github.com/facebook/hhvm/graphs/commit-activity

[pronskiy]

massive performance improvements we saw in v7 and v8

I guess you could say they triggered it, but the actual performance improvements in PHP were carried out by Dmitry Stogov, Xinchen Hui, Nikita Popov, and other contributors, who were neither affiliated with nor sponsored by Facebook.

if they didn't fork and instead put their 50 commits / week into PHP.

It could be yes, but they needed to move much faster and cater vm to their specific needs. From their business perspective, it made total sense to fork. And the PHP ecosystem is very diverse and significantly different from Facebook's requirements.

By the way, this isn't the only example of such a "fork". kphp is another, and Swoole is de-facto yet another one.

[KorvinSzanto]

I guess you could say they triggered it, but the actual performance improvements in PHP were carried out by Dmitry Stogov, Xinchen Hui, Nikita Popov, and other contributors, who were neither affiliated with nor sponsored by Facebook.

I don't mean to say FB did the work, I just mean they spurred the change in part by providing an example implementation and in part by providing serious competition. I totally agree these things happened because of individual contributors who deserve a lot of credit.

From their business perspective, it made total sense to fork. And the PHP ecosystem is very diverse and significantly different

Yeah we're saying the same thing here, I'm just suggesting that PHP would've been better off if FB and/or Slack had any incentive to continue contributing, and I'd even go further and suggest that PHP not really competing with hacklang in this particular space is a negative for PHP.

A good example of that in my mind is @muglug's (Psalm's original author) success at Slack with their psalm-inspired open source hacklang type checker after being effectively hired away from PHP. I think that contrasts interestingly with @muglug himself recently saying that Psalm suffered because of lack of "big industry support"
(albeit specifically as a LSP and not necessarily in general)

[muglug]

The economics of open-source programming languages are weird, and it’s hard to extrapolate any useful lessons because each is its own very specific situation.

The things that make PHP great for 99% of its users (e.g its error-tolerance, metaprogramming via magic methods) make it less great for 1%. I don’t think it’s fair to the 99% to have the 1% effectively hijack the language for their own ends, which is why I’m happy that Hack exists separately.

Vimeo, where I created Psalm, was squarely in the 99% — its use of PHP was not exceptional, nor did its revenue really justify me working on static analysis full time.

Facebook and Slack were definitely in that 1% where it was worth sacrificing some of PHP’s features (e.g. metaprogramming) for a language that’s easier for static analysis tools to reason about.

Supposing Slack was still on PHP, and we created a fast Rust-based tool to analyse our codebase, it would likely not support many PHP features like magic get methods. Contributions from engineers outside the company would be minimal due to Rust’s learning curve. It would never have become Psalm or PHPStan.