Live data from Hacker News

Everything you need (and don't need) to know about PHP's type system

thephp.website

11–20 of 67 posts

Re: Everything you need (and don't need) to know about PHP's type system

#11
Minor nits:

1. "they all inherit from stdClass" -- this is simply not true

2. callables should've mentioned anonymous functions

3. a special typed value can't be casted to anything. -- this is not true, NULLs can be casted to anything (it becomes 0, "", array() ) and even resources can be casted to anything with dubious utility value.

4. casting should mention the intval() , strval() , doubleval() functions

5. php does not support explicit type definition in variable declaration -- PHP 7.4 however supports typed properties. https://wiki.php.net/rfc/typed_properties_v2

Re: Everything you need (and don't need) to know about PHP's type system

#12
> Important to notice that casting an array with numeric keys into an object is valid, but one can't dereference its value because property names may not start with numbers.

Not true, actually. The (admittedly obscure) syntax to access a property beginning with a numeral is `$obj->{0}`. Usually when this happens it's because someone was trying to be clever with JSON.

Re: Everything you need (and don't need) to know about PHP's type system

#13
post #8

While we are on the subject, does anyone know of a way of having required variable declarations in PHP, similar to the way Perl's "use strict" works? This is one of my most common sources of bugs, and it is frustrating not having this be available, when it makes my life so much easier in Perl. Lately I've been thinking about doing something crazy like implementing my own variable system...

> Strict typing mode. In PHP the declare(strict_types = 1); directive enables strict mode. In strict mode, only a variable of exact type of the “type declaration” will be accepted, or a TypeError will be thrown. The only exception to this rule is that an integer may be given to a function expecting a float. https://www.brainbell.com/php/strict-type.html

Worth emphasizing that this directive applies per file, and affects functions called (not those defined) in that file. Not sure if there's a mechanical reason for that, but if I'm writing a new class I'd like some assurances that it's being used correctly. If I could enforce strict types on calling code, I could do away with a certain class of validation.

Re: Everything you need (and don't need) to know about PHP's type system

#14
post #3

PHP rocks in 2020. Couple it with laravel or something and you get a solid platform to build a monolith-type web app with really fast performance.

Isn’t Laravel the worst performing framework out there right now, like even Rails looks like a viable option in terms of speed?

Re: Everything you need (and don't need) to know about PHP's type system

#15
post #13
post #8

Earlier quoted context omitted.

> Strict typing mode. In PHP the declare(strict_types = 1); directive enables strict mode. In strict mode, only a variable of exact type of the “type declaration” will be accepted, or a TypeError will be thrown. The only exception to this rule is that an integer may be given to a function expecting a float. https://www.brainbell.com/php/strict-type.html

Worth emphasizing that this directive applies per file, and affects functions called (not those defined) in that file. Not sure if there's a mechanical reason for that, but if I'm writing a new class I'd like some assurances that it's being used correctly. If I could enforce strict types on calling code, I could do away with a certain class of validation.

The point is supposed to be that once you write in a scalar typehint for a parameter, you don't need to do validation for it being the right type within the function: even if it's called from a non-strict context, that just means PHP will cast it before passing it. So you can avoid type checking code in your function but consumers can still use the more traditional and dynamic style of PHP if they want to.

I can't quite think of the type of validation you'd be able to avoid with the sort of "inverted" strictness you're describing.

Certainly I can think of issues people could have if not using strict types (basically, unexpected casts), but not things that you could actually validate from within the function.

Re: Everything you need (and don't need) to know about PHP's type system

#16
post #9

Adding a static analyzer (like Psalm [1]) to the mixture makes PHP's types much more powerful. Psalm can use docblock annotations to attach more complex types to functions and variables, including: * A "list" type representing a non-associative array * Types representing specific kinds of values, like numeric-string or non-empty-array, as well as exact values as types (like true and false, or string constants). * Typ…

Psalm is nice, however I would suggest PHPStan as an alternative for people that encounter a lot of friction with Psalm.

For example, in a project using doctrine I have to add a bunch of is null/@psal-mutation-free annotations. As all the methods can return null.

However, if Psalm had support for something like phantom types, maybe I could tag entities returned from the database for whom certain fields are guaranteed to have values.

Re: Everything you need (and don't need) to know about PHP's type system

#17
post #14
post #3

PHP rocks in 2020. Couple it with laravel or something and you get a solid platform to build a monolith-type web app with really fast performance.

Isn’t Laravel the worst performing framework out there right now, like even Rails looks like a viable option in terms of speed?

Ruby is slower than PHP7+ by orders of magnitude. I doubt it.

Re: Everything you need (and don't need) to know about PHP's type system

#18
post #12

> Important to notice that casting an array with numeric keys into an object is valid, but one can't dereference its value because property names may not start with numbers. Not true, actually. The (admittedly obscure) syntax to access a property beginning with a numeral is `$obj->{0}`. Usually when this happens it's because someone was trying to be clever with JSON.

There's another way to get a variable starting with a numeral - abusing extract(), I think.

Re: Everything you need (and don't need) to know about PHP's type system

#19
post #16
post #9

Adding a static analyzer (like Psalm [1]) to the mixture makes PHP's types much more powerful. Psalm can use docblock annotations to attach more complex types to functions and variables, including: * A "list" type representing a non-associative array * Types representing specific kinds of values, like numeric-string or non-empty-array, as well as exact values as types (like true and false, or string constants). * Typ…

Psalm is nice, however I would suggest PHPStan as an alternative for people that encounter a lot of friction with Psalm. For example, in a project using doctrine I have to add a bunch of is null/@psal-mutation-free annotations. As all the methods can return null. However, if Psalm had support for something like phantom types, maybe I could tag entities returned from the database for whom certain fields are guaranteed…

Adding Phan to this conversation initially created by the creator of a PHP, now in the hands of TysonAndre who does an insane amount of good work on it

Re: Everything you need (and don't need) to know about PHP's type system

#20
post #13
post #8

Earlier quoted context omitted.

> Strict typing mode. In PHP the declare(strict_types = 1); directive enables strict mode. In strict mode, only a variable of exact type of the “type declaration” will be accepted, or a TypeError will be thrown. The only exception to this rule is that an integer may be given to a function expecting a float. https://www.brainbell.com/php/strict-type.html

Worth emphasizing that this directive applies per file, and affects functions called (not those defined) in that file. Not sure if there's a mechanical reason for that, but if I'm writing a new class I'd like some assurances that it's being used correctly. If I could enforce strict types on calling code, I could do away with a certain class of validation.

Make the changes in your php.ini

Use a configure file that sets env variables for your project files. Put call in that file.

Post reply on HN