Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Quick sanity check ... »

Quick sanity check ...

php.internals

Lester Caine

10 years ago
With all of the debate on the 'type system', can I just ask a probably silly question ;) I'm currently working on porting an application that has been running on windows as C++ code for 20 years. The main reason for changing is that While it worked fine when sites upgraded to XP, the move to W7 and later really needs all the code recompiled, something that will need a big cheque book to buy a current compiler set. So for many reasons a switch to web based using already existing tools makes perfect sense. The database is still running Firebird since the switch from interbase in the late 90's so all of the existing data can be maintained, and I already have a working base on which to build a new set of page templates. ( Only hole is the need for a decent javascript scheduler function to replace the desktop one :( ) This is all running on SQL based schema's which have not changed in years, and ADOdb still quite happily produces arrays of results for which there is little point creating new 'objects', just simply handling the basic variable entries in the arrays just as I have for years. The various tools handle data validation, and 'null' is an essential component of that validation process. This does not need any of the overload of creating 'getters and setters' and I see little point trying to add any 'type' casting into the process since the validation layer simply works with the bog standard variables without and need for 'special cases'. So what benefit does all of the additional 'facilities' now being piled on give that would actually improve that process. I am now seeing a speed improvement on the PHP7 ports, but I'm not seeing any point to make any changes to code OTHER than making the PHP5.2 code clean on PHP7 ... As Zeev has already said "PHP is not broken" ... Do I really need to change the way I work which is running fine for my clients?
-- 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

Guilherme Blanco

10 years ago
I might answer you by given a scenario that happened this week here at work. Because our non-broken language relies on a loose type system, a developer of my company wrote a property that accepts null, int, string, object, whatever as a property. This property was declared in a class that is used in a console command that runs weekly. This property was supposed to hold an integer (value in hours) that would calculate a difference in time and cancel prospected purchases older than this variable hours. All unit tests passed, because they inspect the parts not the whole. By mistake, the developer forgot to provide a value. Nothing was reported in PHP because the language is not broken, and because there's no final and no typed property, no error was reported and code proceed execution. That value that was not initialized and got assigned as null. This value was then converted to 0, and all purchases older than "now - 0 hours" got cancelled. The outcome is easy to grasp. Because it did not crash by a TypeError (which would also require the file to be declared as strict), and we lost 100k in sales. But PHP does not need more strictness... Regards, On Wed, Apr 20, 2016 at 3:22 PM, Lester Caine <lester@lsces.co.uk> wrote:
> With all of the debate on the 'type system', can I just ask a probably > silly question ;) > > I'm currently working on porting an application that has been running on > windows as C++ code for 20 years. The main reason for changing is that > While it worked fine when sites upgraded to XP, the move to W7 and later > really needs all the code recompiled, something that will need a big > cheque book to buy a current compiler set. So for many reasons a switch > to web based using already existing tools makes perfect sense. > > The database is still running Firebird since the switch from interbase > in the late 90's so all of the existing data can be maintained, and I > already have a working base on which to build a new set of page > templates. ( Only hole is the need for a decent javascript scheduler > function to replace the desktop one :( ) > > This is all running on SQL based schema's which have not changed in > years, and ADOdb still quite happily produces arrays of results for > which there is little point creating new 'objects', just simply handling > the basic variable entries in the arrays just as I have for years. The > various tools handle data validation, and 'null' is an essential > component of that validation process. This does not need any of the > overload of creating 'getters and setters' and I see little point trying > to add any 'type' casting into the process since the validation layer > simply works with the bog standard variables without and need for > 'special cases'. > > So what benefit does all of the additional 'facilities' now being piled > on give that would actually improve that process. I am now seeing a > speed improvement on the PHP7 ports, but I'm not seeing any point to > make any changes to code OTHER than making the PHP5.2 code clean on PHP7 > ... As Zeev has already said "PHP is not broken" ... Do I really need to > change the way I work which is running fine for my clients? > > -- > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Guilherme Blanco Lead Architect at E-Block

Stas Malyshev

10 years ago
Hi!
> The outcome is easy to grasp. Because it did not crash by a TypeError > (which would also require the file to be declared as strict), and we lost > 100k in sales. But PHP does not need more strictness...
In other words, somebody wrote code that is supposed to only accept ints but does no checks. Somebody wrote tests that actually don't test anything. Somebody signed off on code that was not properly designed or tested to go into production. And the language is to blame. Right.
-- Stas Malyshev smalyshev@gmail.com

Ryan Pallas

10 years ago
On Wed, Apr 20, 2016 at 2:01 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > The outcome is easy to grasp. Because it did not crash by a TypeError > > (which would also require the file to be declared as strict), and we lost > > 100k in sales. But PHP does not need more strictness... > > In other words, somebody wrote code that is supposed to only accept ints > but does no checks. Somebody wrote tests that actually don't test > anything. Somebody signed off on code that was not properly designed or > tested to go into production. And the language is to blame. Right. >
+1

Guilherme Blanco

10 years ago
The question here is how type strictness would benefit the language. I agree with you on most parts. But still... if the class was declared like this: class CancelOutdatedOrdersDTO { public int $olderThan; } Wouldn't that be solved entirely? Code would crash (through a TypeError), it would never be pushed to production and we would never have experienced this problem. PS: I just gave one example... we didn't actually loose 100k, but I had to spend an hour manually addressing the sales back to pending status. Regards, On Wed, Apr 20, 2016 at 4:01 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > The outcome is easy to grasp. Because it did not crash by a TypeError > > (which would also require the file to be declared as strict), and we lost > > 100k in sales. But PHP does not need more strictness... > > In other words, somebody wrote code that is supposed to only accept ints > but does no checks. Somebody wrote tests that actually don't test > anything. Somebody signed off on code that was not properly designed or > tested to go into production. And the language is to blame. Right. > > -- > Stas Malyshev > smalyshev@gmail.com >
-- Guilherme Blanco Lead Architect at E-Block

Stas Malyshev

10 years ago
Hi!
> The question here is how type strictness would benefit the language. > I agree with you on most parts. But still... if the class was declared > like this: > > class CancelOutdatedOrdersDTO { > public int $olderThan; > } > > Wouldn't that be solved entirely? Code would crash (through a
No of course not. The specific instance of error you had *this time* may be solved. The problem won't be. You still have to deal with: - How this object is initialized? How you ensure it *is* initialized and that initialization is correct (0 is perfectly valid int)? - How this object is unserialized and what if unserialized data has non-integer or 0 or __wakeup has a bug? - What if some code just writes 0 into $olderThan - you declared it as public so anybody could mess with it? - What if some code mixes signed and unsigned and you get negative number instead of positive? - What if this code runs on 32-bit but receives 64-bit value and truncates it? And so on, and so forth, I probably missed more possibilities than I mentioned. Declaring a type does not magically free one from correct design and testing, and typed programs have bugs as much as non-typed ones (maybe slightly different ones). Actually, one of the harms relying on it would be the same problem safe_mode had - it's full of holes, it's not safe and it creates wrong expectations. If you just write "int" and expect your problems to magically go away - you're in for big and bad surprises.
-- Stas Malyshev smalyshev@gmail.com

Fleshgrinder

10 years ago
On 4/20/2016 11:03 PM, Stanislav Malyshev wrote:
> No of course not. The specific instance of error you had *this time* may > be solved. The problem won't be. You still have to deal with: > - How this object is initialized? How you ensure it *is* initialized and > that initialization is correct (0 is perfectly valid int)? > - How this object is unserialized and what if unserialized data has > non-integer or 0 or __wakeup has a bug? > - What if some code just writes 0 into $olderThan - you declared it as > public so anybody could mess with it? > - What if some code mixes signed and unsigned and you get negative > number instead of positive? > - What if this code runs on 32-bit but receives 64-bit value and > truncates it? > > And so on, and so forth, I probably missed more possibilities than I > mentioned. Declaring a type does not magically free one from correct > design and testing, and typed programs have bugs as much as non-typed > ones (maybe slightly different ones). Actually, one of the harms relying > on it would be the same problem safe_mode had - it's full of holes, it's > not safe and it creates wrong expectations. If you just write "int" and > expect your problems to magically go away - you're in for big and bad > surprises. >
While I agree with Stanislav and the others that a stricter type system would not have prevented the bug. However, a stricter type system helps to limit the amount of tests one has to perform and that is often a good thing. That does not mean that dynamic type systems are shit. Actually the opposite is the case, it is the same situation with paradigms. What I love about PHP is that we have a lot under one hood: multi-paradigm as well as loose and strict types. This allows one to choose the best tool for the current job. Relying on your language for a bit of safety as asked of it cannot be compared to `safe_mode` where magic happens in the background. When one declares and `int` than it should be an `int`. Of course that also means that one should know what an `int` is and how to validate it according to the current business rules. That being said, isn't Lester's goal to validate scalar strings all the time anyways? I mean, at least `mysqlnd` transforms all data from the DB automatically to the proper scalar types for optimal performance in your program. But if one keeps scalar strings everywhere and leaves proper type coercion to PHP, I mean, why not. It is definitely doable and strict types are definitely not necessary if done properly. The big difference I see is that Lester is working on his code for himself (or for a customer) and does not have to design APIs for hundreds of other developers. PHP is used in the way it was initially designed, as a glue language. I repeat myself but I cannot see the need for strict types here. If you are developing APIs that are going to be (ab)used by hundreds of other developers in ways you would never have foreseen things change. One wants to ensure that the API is as self-explanatory as possible and as easy to use as possible. This includes (to get back to one of your examples) that objects that should not be serialized are not serializable (`private function __sleep()`) and not deserializable (`private function __wakeup()`) nor cloenable if necessary. This includes self-explanatory required types, sane default values, and appropriate visibility of things. PhpDoc is the classical tool for us here and Stanislav wrote in another thread that this is the tool of choice. I completely disagree with this because PhpDoc might be nice and already features more complicated types (e.g. unions), however, it is also lacking many features as the development of the PSR-5 shows. Another problem is that documentation is not kept in sync and it is extremely hard to teach people how important proper documentation is. Believe me, I know. You might say now that those programmers are bad, well, yes, maybe. But that is what you get when you are working in huge teams; ask Google. In the end it is about better APIs for me as I explained in many other messages and I stay true to that. :)
-- Richard "Fleshgrinder" Fussenegger

Larry Garfield

10 years ago
On 4/21/16 2:11 PM, Fleshgrinder wrote:
> > What I love about PHP is that we have a lot under one hood: > multi-paradigm as well as loose and strict types. This allows one to > choose the best tool for the current job.
^^ That thing. PHP is a very eclectic language. That's a good thing. Does that mean there's a lot to know? To an extent, yes. But frankly, I still find needle/haystack more confusing than any of the new features from the "PHP 6" era (PHP 5.3-5.6) or PHP 7. And things that Zeev is (rightly) encouraging like async primitives would likely be far more confusing for current PHP developers than being able to say "this parameter has to implement both of these interfaces". No one is arguing that typing is a replacement for testing. However, typing is a form of logical proof. Logical proof is a way of demonstrating the absence of bugs, albeit an incomplete one. Testing is a way of demonstrating the absence of bugs, albeit an incomplete one. Testing establishes an upper bound on bugs, while proof/typing establishes a lower-bound. Having robust options for both available lets developers pick one, the other, or both as appropriate for their project. Does that mean "PHP is broken?" No, that's an absurd strawman. Does being against union types or scalar types or property types mean "PHP is perfect?" No, that's also an absurd strawman. But there are unquestionably cases where robust typing is helpful. We should allow that, and encourage the development of more robust typing for those cases where it is helpful. But completely untyped PHP is still 100% legal today and no one on this list is suggesting removing it. Typing in PHP doesn't have to be a strict either/or. That's what's so great about PHP's emerging type system: Typed and untyped code can coexist reasonably peacefully. Can typed and untyped supporters do the same? I hope so...
-- --Larry Garfield

Lester Caine

10 years ago
On 21/04/16 20:11, Fleshgrinder wrote:
> On 4/20/2016 11:03 PM, Stanislav Malyshev wrote: >> No of course not. The specific instance of error you had *this time* may >> be solved. The problem won't be. You still have to deal with: >> - How this object is initialized? How you ensure it *is* initialized and >> that initialization is correct (0 is perfectly valid int)? >> - How this object is unserialized and what if unserialized data has >> non-integer or 0 or __wakeup has a bug? >> - What if some code just writes 0 into $olderThan - you declared it as >> public so anybody could mess with it? >> - What if some code mixes signed and unsigned and you get negative >> number instead of positive? >> - What if this code runs on 32-bit but receives 64-bit value and >> truncates it? >> >> And so on, and so forth, I probably missed more possibilities than I >> mentioned. Declaring a type does not magically free one from correct >> design and testing, and typed programs have bugs as much as non-typed >> ones (maybe slightly different ones). Actually, one of the harms relying >> on it would be the same problem safe_mode had - it's full of holes, it's >> not safe and it creates wrong expectations. If you just write "int" and >> expect your problems to magically go away - you're in for big and bad >> surprises.
Add string handling to that. It's all very well knowing that the variable is a string rather than an integer, but the length ten becomes an important element of the validation.
> While I agree with Stanislav and the others that a stricter type system > would not have prevented the bug. However, a stricter type system helps > to limit the amount of tests one has to perform and that is often a good > thing. That does not mean that dynamic type systems are shit. Actually > the opposite is the case, it is the same situation with paradigms. > > What I love about PHP is that we have a lot under one hood: > multi-paradigm as well as loose and strict types. This allows one to > choose the best tool for the current job.
One problem I'm struggling with is just when enabling 'strict types' is the best tool as with the other type elements that have crept in. Is it easier to handle the validation in a generic way and check for the fine detail which the crude type checks simply miss.
> Relying on your language for a bit of safety as asked of it cannot be > compared to `safe_mode` where magic happens in the background. When one > declares and `int` than it should be an `int`. Of course that also means > that one should know what an `int` is and how to validate it according > to the current business rules.
While some of my client systems are now 64 bit, many of the windows based machines HAVE to be configured as 32 bit simply to maintain access to the hardware. So 64 bit SEQUENCE numbers need to be transparent on 32 bit builds where an 'int' may simply truncate the number?
> That being said, isn't Lester's goal to validate scalar strings all the > time anyways? I mean, at least `mysqlnd` transforms all data from the DB > automatically to the proper scalar types for optimal performance in your > program. But if one keeps scalar strings everywhere and leaves proper > type coercion to PHP, I mean, why not. It is definitely doable and > strict types are definitely not necessary if done properly.
I don't enable mysqlnd if I can help it. I don't use mysql, so my data handling is via ADOdb so my base target is http://hg.lsces.org.uk/hg/Bitweaver%20Mirror/externals/adodb/file/6ca8e39bf7f5/drivers/adodb-firebird.inc.php and if this type checking sugar has any place in there?
> The big difference I see is that Lester is working on his code for > himself (or for a customer) and does not have to design APIs for > hundreds of other developers. PHP is used in the way it was initially > designed, as a glue language. I repeat myself but I cannot see the need > for strict types here.
Bitweaver started off as a port of tikiwiki. It's user base has waned a little, but while tikiwiki lost access to use firebird and some other databases, we maintained that in bitweaver, and while you can use PDO if you insist, ADOdb maintains a level of cross database working that is STILL far superior to the abstractions that are currently playing catchup.
> If you are developing APIs that are going to be (ab)used by hundreds of > other developers in ways you would never have foreseen things change. > One wants to ensure that the API is as self-explanatory as possible and > as easy to use as possible. This includes (to get back to one of your > examples) that objects that should not be serialized are not > serializable (`private function __sleep()`) and not deserializable > (`private function __wakeup()`) nor cloenable if necessary. This > includes self-explanatory required types, sane default values, and > appropriate visibility of things. > > PhpDoc is the classical tool for us here and Stanislav wrote in another > thread that this is the tool of choice. I completely disagree with this > because PhpDoc might be nice and already features more complicated types > (e.g. unions), however, it is also lacking many features as the > development of the PSR-5 shows. Another problem is that documentation is > not kept in sync and it is extremely hard to teach people how important > proper documentation is. Believe me, I know. You might say now that > those programmers are bad, well, yes, maybe. But that is what you get > when you are working in huge teams; ask Google.
PSR is NOT the road map for PHP and has many 'demands' that conflict with a sensible roadmap.
> In the end it is about better APIs for me as I explained in many other > messages and I stay true to that. :)
-- 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

Jesse Schalken

10 years ago
You're blaming humans (devs, testers etc) for a problem which could have been caught automatically (by a strictly enforced type annotation). It follows that you actually *want* writing PHP software to be inefficient, labour intensive and error-prone. On Thu, Apr 21, 2016 at 6:01 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Zeev Suraski

10 years ago
> On 20 באפר? 2016, at 23:33, Jesse Schalken <me@jesseschalken.com> wrote: > > You're blaming humans (devs, testers etc) for a problem which could have > been caught automatically (by a strictly enforced type annotation). It > follows that you actually *want* writing PHP software to be inefficient, > labour intensive and error-prone.
Which is exactly why we're seeing a massive exodus from loosely typed languages like PHP and JavaScript towards strongly typed languages like Java, with people reporting radically better productivity. Seriously. We all know the advantages of strict typing. What seems that we don't all know are the advantages of dynamic typing. And it's no coincidence that in reality, the exodus is going in the other direction, and dynamically typed languages are reported to be a lot more productive. Might you consider reading the research Johannes pointed to? What made you choose PHP? If you think it's fundamentals are so bad and push you to be inefficient, sentenced to hard labor and your code prone to errors, how did you make this horrible choice? Zeev

Stas Malyshev

10 years ago
> You're blaming humans (devs, testers etc) for a problem which could have > been caught automatically (by a strictly enforced type annotation). It
This particular problem maybe could. But it is a symptom of a systemic issue (bad design, bad testing) - curing symptom and leaving the disease is like giving a painkiller to anybody who comes into a hospital without actually seeing what's wrong with them. Usually doesn't end well.
> follows that you actually /want/ writing PHP software to be inefficient, > labour intensive and error-prone.
Of course I do. I hate all humans and ones using PHP especially, that's why I spend so many hours working on it for decades now. Kudos for finally discovering my evil plan. Keep on the good work.
-- Stas Malyshev smalyshev@gmail.com

Lester Caine

10 years ago
On 20/04/16 21:01, Stanislav Malyshev wrote:
>> The outcome is easy to grasp. Because it did not crash by a TypeError >> > (which would also require the file to be declared as strict), and we lost >> > 100k in sales. But PHP does not need more strictness... > In other words, somebody wrote code that is supposed to only accept ints > but does no checks. Somebody wrote tests that actually don't test > anything. Somebody signed off on code that was not properly designed or > tested to go into production. And the language is to blame. Right.
I was thinking "so no one thought to check that the number was the right size?" ... type checks are pointless if you can't even validate the data ...
-- 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

Jesse Schalken

10 years ago
You can continue to use arrays for database records like you always have been. None of the new or proposed features are going to stop you. The concept of type annotations and type systems really has nothing to do with databases directly. It's about adding certainty with regards to the types that are flowing through your PHP program so the program can be modified reliably and predictably. A database is just one possible thing *outside* the program to connect to and interact with using some protocol. Creating a mapping between database records and types PHP objects and types in order to leverage PHP's type system for the purpose of using a databases is quite a complex topic in and of itself, but basically amounts to using some kind of object-relational-mapper such as Doctrine. However, I'm not sure how recent or proposed improvements to typing is related. All I can think of is that Doctrine could make use of type properties instead of PHPDocs for getting column types. You can also just continue to arrays, or a simple class with get($column) and set($column, $value) methods. That's what I do. :P On Thu, Apr 21, 2016 at 5:22 AM, Lester Caine <lester@lsces.co.uk> wrote:

Fleshgrinder

10 years ago
I do not see a single reason why you would need to change anything if you are not requiring any of the new features and would say that the only reason to upgrade for you is security patches. However, I hardly believe that you cannot see a speed improvement; or at least less memory consumption.
-- Richard "Fleshgrinder" Fussenegger

Lester Caine

10 years ago
On 20/04/16 21:11, Fleshgrinder wrote:
> I do not see a single reason why you would need to change anything if > you are not requiring any of the new features and would say that the > only reason to upgrade for you is security patches. > > However, I hardly believe that you cannot see a speed improvement; or at > least less memory consumption.
PHP5.4 http://lsces.org.uk/ 0.41s 3.65Mb PHP5.6 http://php6.lsces.org.uk/ 0.54s 11.77Mb PHP7 http://php7.lsces.org.uk/ 0.45s 1.83Mb Same set of code ... 3 different fpm instances PHP5.2 one with eaccelerator will not run :( but I think I now have PHP7 configured properly with OPcache but it still does not match the speeds I get on the PHP5.2/eaccelerator production machines!
-- 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

Fleshgrinder

10 years ago
On 4/21/2016 2:52 AM, Lester Caine wrote:
> PHP5.4 http://lsces.org.uk/ 0.41s 3.65Mb > PHP5.6 http://php6.lsces.org.uk/ 0.54s 11.77Mb > PHP7 http://php7.lsces.org.uk/ 0.45s 1.83Mb > > Same set of code ... 3 different fpm instances > PHP5.2 one with eaccelerator will not run :( but I think I now have PHP7 > configured properly with OPcache but it still does not match the speeds > I get on the PHP5.2/eaccelerator production machines! >
Well, hard to tell if you could improve further without any info on setup and/or configuration but the numbers look good to me. Also, do not forget that the times and memory consumption you get from PHP might not reflect the real world. I would suggest to measure this with independent tools.
-- Richard "Fleshgrinder" Fussenegger