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
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,
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 - G8HFLContact - 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
Lead Architect at E-Block
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
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
--
Stas Malyshev
smalyshev@gmail.com
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
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
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
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
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 tosafe_modewhere magic happens in the background. When one
declares andintthan it should be anint. Of course that also means
that one should know what anintis 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 leastmysqlndtransforms 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
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:
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
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
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
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
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 - G8HFLContact - 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
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
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
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.83MbSame 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