PHP type system is lacking but I wouldn't call it minimal.
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.
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.
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.
`list<Error>` a `list<T>` is `array<int<0, max>, T>` (some differences in phpstan vs psalm vs mago)
PHP still doesn't have generics, right? IMO any type system without higher-order types is definitely on the minimal side.
One can declare:
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
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(); // DoorI 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.
declare(strict_types=1);
/\* @var array<string, int> \*/
function foo(string $key) {
echo $key;
}
$foo = [
'a' => 10,
'1' => 15,
];
foreach ($foo as $key => $_) {
foo($key);
}
PHP arrays are the most versatile part of the language. They're what actually makes the language so good in so many ways.
But typed arrays are a freaking requirement at this point and I've been screaming about it for years now... alas no response.
I wish that the implicit casting you describe only happened in the two first case. In your example PHP already knows that $foo is a hashmap, so I'd want it to keep '1' as is!
Unfortunately for all of us, for every person surprised by this behavior, there's someone who relies on it. So it'll never change.
Best we can hope is to have better array types eventually (no, the SPL isn't it).