On Fri, Jan 2, 2015 at 12:58 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > > Apart from being consistent with the existing behavior of type > declarations > > We have no existing behavior of scalar type declarations except for > hidden ones in internal functions and object types behave in PHP > completely differently from scalars, so there's no place for > "consistency" claim here. Scalars always has been convertable in PHP, > internal functions accepting scalars always behaved in a coercive and > not strict way. > I'm referring to consistency with existing non-scalar type declarations supported by userland functions. They are strict. Furthermore it should be pointed out that scalars aren't much more "convertable" than other types in PHP. For example it is possible to cast pretty much any value into an array (including scalars), yet nobody is arguing that "array" typed parameters should accept integers as input. PHP in general is very liberal with type conversions, this is not specific to scalars. > > and being what the majority of the vocal community wants, it is also > > I have no idea what "vocal community" is, but what exactly you're basing > your claim of majority on? > By "vocal community" I'm referring to people who state an opinion on this topic in a non-internals discussion. The scalar typehinting proposal has come up many times over the years in many minor variations and every time discussions on reddit etc are dominated by the preference of having strict type declarations. In various OTR conversations this was also by far the most common opinion I heard. The "vocal" was explicitly mentioned because I realize that this sample is subject to selection bias. > > possible to reason about strict type declarations statically. > > You can reason about coercive declaration as well as you can reason > about strict one. > I am referring to weak typehints as described by this particular proposal. Yes, you can of course perform static analysis even in the presence of implicit conversions. However the problem with this proposal, and all other similar proposals I have seen, is that the *type* check is *value* dependent. E.g. saying "integers and floats are accepted for float parameters" is okay from a static analysis perspective, whereas "strings are only accepted for int parameters if they contain decimal integers" is not. Additionally this particular proposal at least is loose to the point of making static analysis pointless even in the cases where it can be done. E.g. if even something obviously wrong like passing "foobar" to a boolean argument cannot be detected as incorrect code (because it would be accepted by PHP), then I don't think doing type analysis would have any value. > > For the same reason loose typehints are also more fragile. Code that > worked > > in casual testing during development will fail in production when > > unexpected, improperly validated user input is encountered. With strict > > types on the other hand it is very likely that code working with one > input > > will also work with all other possible inputs, because the type check is > > Since all the inputs are ultimately strings for PHP, so you'd have to > convert from string to other types somewhere, and if that code does not > perform properly on certain input, you still get a failure. You are just > moving the failure around. And of course the claim "if the code works > correctly with one integer input it would work correctly with any other > integer input" is wildly incorrect. In fact, type errors (if you define > types broadly as string/integer) are a tiny minority of logic errors in > software. > I was probably not sufficiently clear here. Strict type declarations force you to explicitly validate&cast any input you receive from the user in stringified form. Because of this you will always provide a valid type to the function, irregardless of what the user entered. With weak typehints on the other hand you will get away with working directly on unvalidated input (like passing $_GET['id'] directly to an int-hinted parameter). Usually. However when the script is called with ?id=abc you will get a runtime error. That is what I'm referring to when I say "more fragile". > ability to check correct usage with tooling. I'd also like to point out > > that Hack uses a strict type scheme and it seems to work well there > (though > > Java uses strict typing too. And Perl has no typing whatsoever. So what? > How bringing an example of one language that does what you want is an > argument for PHP to do that? There are examples of languages doing > practically anything imaginable. > Hack is very similar to PHP. If something works for Hack it is likely to also work well for PHP. Be realistic. I'm not trying to sell you algebraic data types because they're nice in Haskell, and I'm not trying to introduce Lisp macros either. I'm talking about a language that is *derived* from PHP. I think Hack is a nice playground for new PHP features and we should be incorporating the parts that turned out to be useful. > > > Just look at the conversion table in the RFC, practically all of it is > > "Yes". I understand the motivation to reduce the number of different > > How many "yes" is a bad thing? > Yes. There's a tradeoff between convenience of usage and how many bugs the type checking catches. For maximum convenience we can just allow all types for all hints (there was one proposal to do this - effectively this would make the typehints documentation only). For maximum correctness we allow only the specified type. I prefer correctness over convenience, but I understand that others have different opinions on this. Nikita
