PHP 7 and declare(strict_types=1);

First of all Happy New Year and a very big thank you to all the Development Team because...

I recently installed PHP 7 and delighted to say that no modifications were required.

I am now in the process of using the new PHP 7 features and discovered:

<?php # trying to implement strict_types:

/** must be the  FIRST declaration
 *
 *    and is ONLY file wide
 *
*/
declare(strict_types=1);  # accepts 0 as a toggle-off

Is it possible to globally toggle this feature?

I tried setting  php.ini auto_prepend= 'TOGGLE-STRICT.php' but it only applies to the file

I tried defining a TOGGLE_STRICT constant in the TOGGLE-STRICT.php which was accepted BUT failed when I tried this:

<?php
if ( defined( 'TOGGLE_STRICT' ) ) {
  declare(strict_types=1);
}

# ERROR MESSAGE:
# Fatal error: strict_types declaration must be the very first statement
# in the script in /home/john/www/a-tests/ds-rating/test-001.php on line 5


Nearly forgot using this feature on index.php revealed that ini_set('display_errors',1); fails because the second parameter requires a string.

Also discovered that the this script is not acceptable because of the preceding trailing-slash:

#protected function testFunction(( \string $name, $values = null)

# BUT this script works OK:

protected function testFunctioMUST BE THEn( string $name, $values = null )
{
 ...
}

strict_types=1 can only apply to a file that directly declares it on its first line, no way around that.

And that's a good thing - you're not supposed to force it on code that's not written in a strict manner. The bad thing is this doesn't apply in both directions and you can turn strict_types off for a function/method that has been declared under strict rules.

narf


>>> strict_types=1 can only apply to a file that directly declares it on its first line, no way around that.
Yes I have tried and not been able to get round it


>> And that's a good thing - you're not supposed to force it on code that's not written in a strict manner. 
Why not? At least be fully aware of the potential problems and allow optional rectification.

>>> The bad thing is this doesn't apply in both directions and you can turn strict_types off for a function/method that has been declared under strict rules.
After extensive playing with the strict feature I get the general impression that PHP 7 is totally strict. I am now in the process of getting my files to conform


As mentioned I would have far preferred to have a global switch which would still allow the application to run but would be bloated because ot the generated warnings. Using strict and without any generated warning would produce a lean, mean application, performing a lot faster and use less memory (ideal for mobiles?) I think most compiled languages have this "strict" feature.

>> And that's a good thing - you're not supposed to force it on code that's not written in a strict manner. 
Why not? At least be fully aware of the potential problems and allow optional rectification.

How do you mean why not? The answer is in the quote - it's code not written for strict mode; likely not your own code (if it's your code, you'd declare strict_types) and you'd have no control over it.

>>> The bad thing is this doesn't apply in both directions and you can turn strict_types off for a function/method that has been declared under strict rules.
After extensive playing with the strict feature I get the general impression that PHP 7 is totally strict. I am now in the process of getting my files to conform

IMO, it is bad that there's a strict mode in the first place and that strictness could've and should have been achieved with explicit syntax. Any time that you look at a piece of code and can't be sure at 100% how it will behave, it's a sign of something bad.

As mentioned I would have far preferred to have a global switch which would still allow the application to run but would be bloated because ot the generated warnings. Using strict and without any generated warning would produce a lean, mean application, performing a lot faster and use less memory (ideal for mobiles?) I think most compiled languages have this "strict" feature.

Such modes are "evil", read above.

Such modes are "evil", read above.

To answer your previous points, the reason I would like to have a global strict option is to be able to highlight and rectify Exceptions.

The following is a typical example that occur when declare(strict_types=1); is applied to:

file: index.php:

An uncaught Exception was encountered

Type: TypeError

Message: ini_set() expects parameter 2 to be string, integer given

I believe that eliminating that and other possible Exceptions will make CodeIgniter just a little bit faster.

Such modes are "evil", read above.

To answer your previous points, the reason I would like to have a global strict option is to be able to highlight and rectify Exceptions.

The following is a typical example that occur when declare(strict_types=1); is applied to:

file: index.php:

An uncaught Exception was encountered

Type: TypeError

Message: ini_set() expects parameter 2 to be string, integer given

I believe that eliminating that and other possible   Exceptions will make CodeIgniter just a little bit faster.

If you have to explicitly cast from int to string for that call, that's one more instruction for PHP to execute instead of doing the same job automatically - you gain nothing from that. Even in the rare cases where you could direcly change the type without a manual cast, the benefit is neglible.

That being said, I don't mind such optimizations, but if you're willing to do the work to go through all of them, don't tell me you're too lazy to put a single line per file for development purposes.

Either way, it doesn't matter - that's how the language works and we can't change it.

That being said, I don't mind such optimizations, but if you're willing to do the work to go through all of them, don't tell me you're too lazy to put a single line per file for development purposes.

OK, done, modified 183 files

Online results:

http://tools.pingdom.com/fpt/#!/mF90Q/ht...jokes.com/

I hope to have a go at CI - ver: 3.0.3 tomorrow.