Hello, On Thu, Feb 26, 2015 at 12:49 PM, Dan Ackroyd <dan...@basereality.com> wrote:
> On 26 February 2015 at 17:48, Zeev Suraski <z...@zend.com> wrote: > >> From: Theodore Brown [mailto:theodor...@outlook.com] > >> 2. Strict types are important in some cases. > >> > >> I would *want* any value with the wrong type (even a string like > > "26") > >> to be flagged as an error when passed to a function expecting an > > integer. > > > > > > I agree completely; However, such use cases like this are a lot less > > common than the situations where you do want sensible coercion to be > > allowed. > > > That's just not true on medium to large code bases, and if you think > that's true it's possibly an explanation of why you don't see why > people want strict types so much. > I've worked on several very large and medium sized code bases and I would prefer sensible coercion to be allowed here. This is likely more a matter of presence. More information below. > > In most applications, the part of the code that is exposed to the > outside world and has to convert strings or unknown types into known > types is a very small layer at the outside edge of the application. > This is true, however, the types that you are receiving back form a multitude of data sources might be in a mixed format (databases for example often provide representation back as a string, non-json based web services provide mainly as a string, etc). While I know what my data looks like and I know I am always going to get a "string" integer back I do not want to have to type cast this each and every time. Or that I have a boolean integer representation that is in a string... You get the point. Sure, I could certainly go in and take 5 minutes and cast each one but I'm not certain why the purpose is there... It specifically changes the determination that PHP is a weakly typed language and all of a sudden I now need to care that my string integer boolean is not actually a boolean. > > The vast majority of code written for non-trivial applications has no > contact with the outside world. Instead it only communicates to other > layers inside the application where the types required are fully > known, and so the parameters passed should already be in the correct > type. And so type coercion is at best unneeded, and usually not > wanted. > Yes, we're talking about a service oriented architecture or busways, etc. Even then, between multiple layers of the onion you might have things that are going to [a]synchronous message queues, coming from extensions, going against a file system, etc. A non-trivial application has to go against all of these things and the types might be different for each one of them. For instance, PHP's integer does not handle a big integer from a database after it exceeds a certain amount of digits, you have to speak binary to a screen but you have an integer representation and then you might even need to convert to a string octal in some points. Overall, what I am saying here is that it is a mixed bag of tricks and each developer happens to have their preference to how the type system should and should not work. > I can understand why people might only want to use weak types for > their code base, but for you to continually dismiss people's desire > for strict types after all this has been explained to you multiple > times is very depressing. > I am not sure that Zeev is dismissing it so much as that he does not agree with it and therefore he is doing his best to find an alternative that remains within his vision of the PHP landscape. That is why we have multiple options on the table at this point. Regards, Mike
