Yes it is rather a neat feature and I am trying to think of the best usage. It is good that I can use it on locally and it will have no effect on files uploaded to the server.
The usage I had in mind was for a PHP Framework which uses quite a few libraries, controllers, models, views, etc. I was hoping to be able to toggle the feature and gradually eliminate the new found errors, warnings and to update the code. (I should imagine it will not be an easy task but rather an ongoing project.)
Using the ā** recursive r+ file writing**ā would hard-code the script and I should think create problems
###Edit
I defined a boolean TOGGLE_STRICT constant in the included auto_prepend file and can now safely write a recursive r+ file.
<?php
if ( defined( 'TOGGLE_STRICT' ) ) {
declare(strict_types=1);
}
Above is yet to be tested.
Test Results:
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
Personally, I hope strict_types is used sparingly and for most cases Iām not a fan of this. Why? Because itās against the nature of PHP, which is inherently weakly typed - all internal functions and operators operate in weak type mode and I think for consistency sake itās a bad idea to introduce strict typing. If mixed, we will end up in two type opposing paradigms and for the developers it is not immediately obvious whether a methodās signature is weakly or strictly typed. Itās like trying to make PHP behave like a different language. I think the default scalar type hinting added in PHP 7 has been done very sensibly and is following the overall weak typing that has existed in PHP from the beginning - and Iām really fond of how it functions - checking for correct values and type casting to the desired type. If a function requires an integer I want to be able to pass it a string value of ā7ā - just because thatās what has always worked and is consistent.
Iām aware that this may be a controversial topic and Iām not saying one typing system is better than the other. I just think that mixing the two may become messy. If strict typing is ever used by developers I hope they use it only for their internal classes - but leave weak typing for their external APIs.
You would almost certainly have to right? I mean even in C#, a strongly typed language, your API exposure is usually an XML or JSON object coming in, an XSD may validate it, but you still have to cast it down internally to the actual type you want it to be and send back an error when you get something you donāt expect.
Well, I didnāt really mean āexternalā in such an extensive sense as communicating with other systems via XML or JSON. I meant PHP libraries which expose their API to the programmers that use them in their projects - the API is usually a set of PHP classes with their public methods.
Iāve just tested declare(strict_types=1) and fortunately it cannot be used to enforce strict typing to the outside caller as I initially suspected. So a library developer cannot require its users (programmers) to use strict types when calling methods of the library - and the arguments will be type cast in a weak fashion by default. declare(strict_types=1) affects the calling code only so in this case all the power is in the hands of the library user. Whether the library developer uses strict_types or not will affect only the library classes, not the code that calls them. Seems reasonable.
Ah, yes, I think I recall that from the RC when strict types were being debated. I sort of see those APIs similar to fully external APIs too though. Anytime you include an additional library, you have to assume (as the library) that any input could be invalid or in a format you didnāt expect. Handling that the best you can should always be something we devs strive to do.
I sort of agree and also think it is too late to try and introduce this feature, far better off to introduce a new PHP Mandatory Strict Typed Version possibly called PMS?
At least this introduction to using strict types is a start although 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.
PHP started about 20 years ago and has cultivated a vast amount of programmers with sloppy habits. I doubt very few know of GIGO.
[Off Topic] This change reminds me when UK seat-belts were first made compulsoryā¦ how many modern drivers still do not use a seat belt? Personally I think all drivers should have a 12 inch sharp spike protruding from the steering column and not be allowed to wear safety-belts
I mostly agree with you, however we need to remember that handling invalid formats āas best as we canā may come at a cost of degraded performance and added complexity so the programmer has to decide how far to go in dealing with invalid inputs. Often it is not worthwhile to do elaborate input checking and the new scalar type hinting is a simple and fast way of dealing with invalid data - just type hint an argument and PHP will do the rest by throwing an exception in case of a bad value - in many cases this will be sufficient.
BTW, I have found a small new undocumented feature of PHP 7 - now it is possible to access class constants from an object instance saved in a property:
$c = $this->obj::MY_CONST;
In previous PHP versions an intermediate variable had to be used:
I still see that as a valid way of validating your input (as you had to tell PHP the hint). Hinting and letting the language do most of the work is definitely okay from where I stand, and then the programmer simply does the additional checks that PHP might not be able to do, is it in the format of XXX-XX-XXXX (when checking SSN), or what have you. Either way, you as a programmer took steps to validate the input by either letting the language do its part with its own type casting or adding additional logic to ensure what PHP canāt do alone is covered.
Interesting. I havenāt read the whole thread yet, but on the topic of global strict typing, I asked about it (canāt remember who), if it would be possible to make a global setting. I got the answer that it would be troublesome to do, as it might cause a lot of libraries and extension to break. I didnāt reply, as I didnāt want to push the subject, but my first thought was, āMaybe that isnāt such a bad thing after all?ā. Strict typing is needed to make JIT compilation a reality, which I would very much like to see. Iād like to see the critics be quieted, who keep saying PHP isnāt built for highly computational work.
Yes. This is one of the things I love about C#. I love that it can be compiled and it actually does have some weak typing aspects built in in a psuedo way. The var keyword for example, doesnāt tell you what must be received, but rather, that whatever value it does receive will become its type during compiling/runtime.
I actually like type hinting in PHP, I type hint just about everything now. Making it feel more strict and errors more obvious when you pass in the wrong object or what have you. I imagine a lot of other programmers will eventually move that direction, making most libraries utilizing type hinting, and thus make it easier to move to a global stict option. I believe such an option can exist, it just canāt be made default (yet and maybe never). It would then be up to each application to determine if they can enable it, if they can, great! If they canāt because of an external library, maybe push a patch to that library to make it work? (or ask them to consider making it work).
I think there are a lot of advantages to PHP supporting JIT compilation. It would drastically improve performance (even though they managed to do that with PHP 7 in other areas).
Is compilation impossible with weak typing? I understand some performance improvements can be done for compiled strict code but would weak compiled code be so much slower (if possible at all)?
No, it isnāt impossible, it just requires some dynamic compiling/interpretting at runtime. So if you do a lot of weak typing (without hints) throughout your application, your performance will likely be greatly impacted because what could be compiled, ended up being little to nothing and instead it is dynamically interpretting most of your variables on the fly.
If you use hints, the compiler can be more intuitive during compilation and optimize the output to run more efficiently.
Probably the best solution would be to have the strict mode optional in such a way that a compiler could make use of it with all optimizations - then developers could choose to use strict mode in any part of their application that they wish to compile to more efficient code. But I donāt think this will come any time soon because strict mode is not only about argument hints but also all internal and extension functions and built in operators - all that would have to be changed to operate in strict type mode, which I presume is a lot of work.
Overall, I think the only significant new features in PHP 7 that can affect in a serious way designing application structure are argument hints, return types and the error handling with exceptions. All the other features are minor convenience improvements - they are great improvements nevertheless but nothing that change the way we structure applications. Which I think is good - itās a mixture of new features that allows for a fairly good level of backwards compatibility.
