It's had return type declarations since 7. There's even intersection and literal types now. You could have typed this into google and it would have told you
Type declarations are still quite limited, though. For example, you can declare that a function returns an array or a string, but not an array of strings.
You can annotate the method as `@return array<array-key,string>` or even `@return list<string>` (array of strings = indexed via anything that can be used as a key in PHP vs list of strings = indexed via incrementing integers, starting from 0). I guess the OP suggestion was to use Arrayable / Iterable interfaces, which would work as well, but would require more effort (= yes, declare a class)
You remember when HHVM / hack came out from Facebook? Besides the fact that it was quite a dick move from Facebook to bring it out and then stop supporting it, it pushed PHP to take performance temporarily serious and there was so much air in it.
But the standard library is still inconsistent as hell, type system is still garbage especially mixxing strict and non strict.
The concurrency implementation? Has to be fixed again by frameworks.
And yeah i mean the critisism of my original comment stands as well and thats just an eye sore.
PHP does have return type annotations. The reason the PHPDoc comments are needed here is that it lacks generics. Unfortunately, adding generics has proven problematic, but I still hope that we'll see them in the next few years.
I dunno,unlike the crypto/NFT era, Rust rewrites have demonstrated measured performance and memory savings gains. Some grimace when they see "written in Rust" as a tagline but my immediate thought tends to land more on the "thank God this isn't an electron app" side of things
Operative word is “fanboys”, I have mostly no qualms of actual rewrites to that language. It’s the fanboys who insist upon injecting themselves and their opinions everywhere with net negative impact.
For anyone not familiar with PHP, static analysis is pretty much required because the official PHP type system is minimal. The detailed types are added through phpdoc comments, and they also help IDEs to provide a sane completion. For instance, the plain "array" should be detailed with phpdoc:
/**
* @param array<string, MyRecord> $input
* @return list<int>
*/
function foo(array $input): array
{
foreach ($input as $string => $record) {
// IDE knows $record is an instance of MyRecord
The static analysis will use both type systems, and it's the only way to check that phpdoc are consistent. Psalm has various levels of strictness, and even at a very lax level, it can help detect errors or code smells.
There are two major static analysis tools for PHP, Psalm and PHPstan, both written in PHP. The latter used to be much slower, but last time I tried it there was little difference (about 20 s for 100k lines + dependencies).
My guess is that a new contender, Mago, written in Rust, will probably soon replace those other tools. Its commands (analyze, lint) are already almost as complete as psalm/phpstan. Though the migration won't be easy because it does not have a notion of levels.
That's exactly it but PHP Core refuses to address the typed array issue in wait for a consensus on Generics even though those two things serve different audiences.
I haven't actually run into a single issue with PHP's type system in the last few years. Literally the only thing that remains is typed arrays but that seems to be ways off due to fragmentation in how the core devs want it handled.
With how good PHPDoc and Phan are these days I don't really think about it anymore. You can sort of have typed array by implementing Iterator, Countable, ArrayAccess, and optionally Indexing but I assume you mean defining types of array values.
final class Door {}
/**
* @template T
*/
final class Box
{
/** @param T $value */
public function __construct(private mixed $value) {}
/** @return T */
public function get(): mixed
{
return $this->value;
}
}
final class DoorInspector
{
/** @param Box<Door> $box */
public function __construct(private Box $box) {}
public function inspect(): void
{
$this->box->get()->open(); // analyser knows this is a Door
}
}
new DoorInspector(new Box(new Door())); // OK
new DoorInspector(new Box('not a door')); // error: Box<string> given
You can even bind a template by a generic type with "of":
final class Door {}
/**
* @template T
*/
class Box
{
/** @param T $value */
public function __construct(private mixed $value) {}
/** @return T */
public function get(): mixed
{
return $this->value;
}
}
/** @extends Box<Door> */
final class DoorBox extends Box {}
/**
* @template T
* @template F of Box<T>
*/
final class Shelf
{
/** @param F $box */
public function __construct(private Box $box) {}
/** @return F */
public function box(): Box
{
return $this->box;
}
/** @return T */
public function item(): mixed
{
return $this->box->get();
}
}
$shelf = new Shelf(new DoorBox(new Door()));
$shelf->box(); // DoorBox
$shelf->item(); // Door
Maybe "minimal" was not the right word. I hope the context made clear that I meant the type system was lacking even for basic uses. Here are 3 common cases.
Some PHP functions (e.g. opening a file) return a `resource` type, but PHP has no official way to declare it. So the right way is to declare `mixed` as an official type (which means `any`) and fix that declaration with a phpdoc comment.
Phpdoc provides generics (named "templates", à la C++), e.g. `iterable<Something>` where `iterable` is an official PHP type (which is awfully imprecise without phpdoc).
Phpdoc has tuples and (associative) array shapes, e.g. `@return list{int, \Error}`.
In past PHP versions, the type system was worse because the internal types were ambiguous: types were implicitly nullable, i.e. `string` meant `null|string`. When PHP gradually added sum types, they fixed that ambiguity.
origini | 6 hours ago
Come on PHP has so many shitty things, but even something basic like this is still not in the lanuage itself?
monster_truck | 6 hours ago
bakugo | 5 hours ago
lofaszvanitt | 5 hours ago
bakugo | 4 hours ago
lofaszvanitt | 3 hours ago
origini | 3 hours ago
Because if yes, thats just ugly and a hack/workaround.
eithed | an hour ago
origini | 5 hours ago
Y-bar | 6 hours ago
origini | 5 hours ago
Including generic type arrays which is not supported.
spiderfarmer | 5 hours ago
origini | 5 hours ago
wesammikhail | 4 hours ago
ooh wait, you couldn't be more wrong. Pikachuface.png
origini | 4 hours ago
You remember when HHVM / hack came out from Facebook? Besides the fact that it was quite a dick move from Facebook to bring it out and then stop supporting it, it pushed PHP to take performance temporarily serious and there was so much air in it.
But the standard library is still inconsistent as hell, type system is still garbage especially mixxing strict and non strict.
The concurrency implementation? Has to be fixed again by frameworks.
And yeah i mean the critisism of my original comment stands as well and thats just an eye sore.
throw1234567891 | 5 hours ago
pkkm | 2 hours ago
anthk | 6 hours ago
Y-bar | 5 hours ago
wesammikhail | 4 hours ago
scronkfinkle | 3 hours ago
Y-bar | an hour ago
RunSet | 2 hours ago
"Strange; seems like all I hear about these days are projects funded by the world's largest advertising corporation."
hiccuphippo | 2 hours ago
idoubtit | 4 hours ago
There are two major static analysis tools for PHP, Psalm and PHPstan, both written in PHP. The latter used to be much slower, but last time I tried it there was little difference (about 20 s for 100k lines + dependencies).
My guess is that a new contender, Mago, written in Rust, will probably soon replace those other tools. Its commands (analyze, lint) are already almost as complete as psalm/phpstan. Though the migration won't be easy because it does not have a notion of levels.
bel8 | 4 hours ago
PHP even has union types, just like TypeScript.
The major issue is the lack of array types and it's 90% of the reason I see projects using extra linting tools.
[1] https://php.watch/versions/8.0/union-types
wesammikhail | 4 hours ago
I haven't actually run into a single issue with PHP's type system in the last few years. Literally the only thing that remains is typed arrays but that seems to be ways off due to fragmentation in how the core devs want it handled.
hparadiz | 4 hours ago
Timon3 | 3 hours ago
PHP still doesn't have generics, right? IMO any type system without higher-order types is definitely on the minimal side.
eithed | 2 hours ago
One can declare:
You can even bind a template by a generic type with "of":someothherguyy | 9 minutes ago
someothherguyy | 27 minutes ago
idoubtit | 26 minutes ago
Some PHP functions (e.g. opening a file) return a `resource` type, but PHP has no official way to declare it. So the right way is to declare `mixed` as an official type (which means `any`) and fix that declaration with a phpdoc comment.
Phpdoc provides generics (named "templates", à la C++), e.g. `iterable<Something>` where `iterable` is an official PHP type (which is awfully imprecise without phpdoc).
Phpdoc has tuples and (associative) array shapes, e.g. `@return list{int, \Error}`.
In past PHP versions, the type system was worse because the internal types were ambiguous: types were implicitly nullable, i.e. `string` meant `null|string`. When PHP gradually added sum types, they fixed that ambiguity.
someothherguyy | 16 minutes ago
`list<Error>` a `list<T>` is `array<int<0, max>, T>` (some differences in phpstan vs psalm vs mago)