Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Type locked variables »

Type locked variables

php.internals

Michael Morris

9 years ago
Perhaps it's time to revisit the idea of allowing variables to have their types locked down. The keywords needed are already reserved. So... string $a = "hello"; int $b = 5; Once declared this way the variable's type won't change unless it gets unset. In normal mode PHP will coerce any assignment to the variable to the desired type. If declare strict types is on then assigning the wrong type to a variable would raise a type error. Note this would simplify one of the use cases of setters - insuring the class member is of a valid type. The idea of function overloading reminded me of this. I'd consider being able to do this sort of type lockdown to be prerequisite to having overloaded functions. Since this approach is entirely opt in I don't think it would make the language harder to learn.

Alice Wonder

9 years ago
On 11/15/2016 03:44 PM, Michael Morris wrote:
> Perhaps it's time to revisit the idea of allowing variables to have their > types locked down. The keywords needed are already reserved. So... > > string $a = "hello"; > int $b = 5; > > Once declared this way the variable's type won't change unless it gets > unset.
++

Daniel Morris

9 years ago
On Tue, 15 Nov 2016, at 11:44 PM, Michael Morris wrote:
> Note this would simplify one of the use cases of setters - insuring the > class member is of a valid type.
It's already possible to ensure within a setter that the variable is of a specified type, you only need to make the instance variable private and scalar type hint the method arguments within the setter (provided that strict_types is set), I think this would be more likely to lead to code littered with calls to unset rather than to provide much benefit, and as far as I'm aware, there's no real performance benefit that can be gained from this as of yet since the variables will still be a zval internally.
-- Daniel Morris daniel@honestempire.com

Guy Marriott

9 years ago
I think it would make more sense for typed properties to exist first, and it so happens that there was a recent RFC for this: https://wiki.php.net/rfc/typed-properties. That RFC failed by a very small margin. I would suggest you read through the discussions on the mailing list regarding that RFC for some common arguments to typing in PHP. On Wed, Nov 16, 2016 at 12:44 PM, Michael Morris <tendoaki@gmail.com> wrote:

Lester Caine

9 years ago
On 16/11/16 00:06, Guy Marriott wrote:
> I think it would make more sense for typed properties to exist first, and > it so happens that there was a recent RFC for this: > https://wiki.php.net/rfc/typed-properties. That RFC failed by a very small > margin. > > I would suggest you read through the discussions on the mailing list > regarding that RFC for some common arguments to typing in PHP.
It really does feel that it's time for a complete split between the simplicity that PHP has traditionally provided by NOT requiring everything is tied down in the straight jacket of 'strict typing' and a version of PHP that only works for that style of user. Things like 'function overloading' and 'int $b = 5;' do not simplify anything if you are using PHP to get away from the 'annoyance' of having to worry just how '5' was supplied. That it is an integer is only a small part of verifying if it is actually a valid input and handling mistakes or even hack attempts are not solved by simply throwing out of line errors due to a different style of working. Simply adding a range check on an input keeps the fault in the right place and perhaps allows 'five' to be responded to with a correct response ... What is STILL needed even if you make PHP only strict is a proper validation of the data contained in those 'restricted' pots ... and I include validation that an in variable is 8, 16, 32, 64 and today even bigger which is where the need for strict typing originated, and function overload to handle a multiple of fixed variable sizes.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Yasuo Ohgaki

9 years ago
Hi Michael, On Wed, Nov 16, 2016 at 9:06 AM, Guy Marriott <php-lists@scopey.co.nz> wrote:
> I think it would make more sense for typed properties to exist first, and > it so happens that there was a recent RFC for this: > https://wiki.php.net/rfc/typed-properties. That RFC failed by a very small > margin. > > I would suggest you read through the discussions on the mailing list > regarding that RFC for some common arguments to typing in PHP.
In addition, type safety provides limited safety. e.g. Range checks are mandatory for safety. DbC provides more powerful features to ensure proper operations without production environment overheads. https://wiki.php.net/rfc/introduce_design_by_contract https://wiki.php.net/rfc/dbc https://wiki.php.net/rfc/dbc2 In order to exploit power of DbC, we need usable/easy to use validation feature like https://wiki.php.net/rfc/add_validate_functions_to_filter though. i.e. Most DbC checks are omitted in production environment, therefore validation function that is executed in production environment is mandatory with DbC. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net