[quote=“tpunt, post:21, topic:217759”]
And it’s because of this simple reason why I’d like to see PHP catch more of those mistakes for us, hopefully easing development time.[/quote]
Don’t know for sure, but I would imagine there is a tradeoff. Since PHP is an interpreted language, having it “checking” for a lot of extra things, to me, could possibly cause the performance to drop.
This, being strict about types and the compilation step needed for some languages make them a PITA to learn and master. Though, I think once PHP gets a JIT compiler, we’ll be talking again, and a lot more, about type strictness.
If you think about it though, PHP is a great language, because it let’s the novice do simple things (even wrong) and get a quick and semi-effective result. That provides those beginners with encouragement to do more. I hope the low entry threshold to start with PHP and the ability get things done relatively quickly will never be lost.
Yeah, further analysis checks will affect performance, but there’s more to it than that. PHP isn’t strictly an interpreted language. During execution, it is firstly lexed, then parsed, then compiled into opcodes, which are then run on the Zend VM. So really, it could be considered a compiled language but with a highly dynamic runtime.
With OpCache enabled (or any form of opcode cache), the compilation time (including the lexing and parsing times) are mitigated, since the VM only needs to execute the opcodes when running a script. I’d like to see a solution in future to have extra analysis checks done by the engine when in development mode (a new .ini setting?), but I can’t see it happening soon.
Whilst the strictness can be a PITA, it does help mistakes to be caught quickly. But for the record though, I’m more against than for typing in PHP. I like my dynamic languages, and Elixir manages to be compiled, dynamic, and very fast, so adding types everywhere is not exactly a solution for extra execution speed.
Completely agree . I still enjoy programming in PHP, and I will still actively contribute the project. I just prefer what other, more modern languages are doing.
Cool! Good to know we have internals devs within our modest PHP community here at Sitepoint. BTW, the PHP docs are also one of the plus points that help PHP stand out.
Getting off topic, but what do you think about the RFC to standardize the function names? What I am interested in is, is it being discussed at all, to get it done? Or rather, is there any concerns in the internals team about making PHP more standardized?
It is not being discussed at all (not in the past year, at least). Even if it was under discussion though, the likelihood of it passing would be very slim unless a completely rock solid plan could be formed (and subsequently backed by the majority of internals).
Part of the problem with standardising all function names (and parameter orders, according to the RFC), is the size of PHP’s standard library. I believe it has over 5,000 functions at the moment, and that will take a tremendous amount of effort to go through each and every one to check that they all have consistent names and parameter orders. There aren’t many internals developers, and their combined finite amount of resources aren’t worth spending on this. Many are working on more important things (like engine optimisations and new features for PHP 7.1).
Not only that, PHP’s inconsistent function names and parameter orders are well known by the community. To introduce a new set of APIs would effectively mean having to learn a whole new standard library. Plus, given the upgrading rates to newer PHP versions, many would avoid using the new standard library for a number of years anyway (though I expect a polyfill would sooner be introduced anyway).
For now, it’s a problem that’s seen as already having a solution: use an IDE. IDEs should be able to use their intellisense or other suggestive features to help developers with function names and parameter orders.
Overall, I personally don’t have a strong opinion on this. Would it be nice to have a standard library that’s consistent? Yes, absolutely. But given how much PHP code is already out there, I can see that having two APIs that do the same thing will most likely lead to them both being used in a single code base, and that would be pretty ugly to maintain/develop.
I think the problem here is what standard should be followed, and when should it be followed. Should underscores be used to separate words (random_int() and random_byte()), or just lowercase everything (intdiv()), or use camel-case? Trying to be consistent with PHP’s inconsistent library isn’t easy And whichever consistency style is chosen, it will not make sense to use in every core extension.
For example the BC Math extension uses all lowercase without underscores, whereas the GMP extension uses all lowercase with underscores. This is why even the newly added functions (mentioned above) still aren’t consistent with each other. So I think the more important thing is to remain consistent with the extension’s conventions, otherwise you end up with a complete mess (as seen with the the str* functions in SPL).
