Hi! > I'm referring to consistency with existing non-scalar type declarations > supported by userland functions. They are strict.
There's no choice here as object types are not convertable in principle (well, not unless we do convert ctors like C++ but IMHO that would be a bit crazy). You can't equate primitive types in PHP with object types - they just work differently and there can not be "consistency" between them unless you rewrite PHP to be strongly typed language with no implicit type conversion. It's not unheard of - Python is like that - but it's not what PHP is now. > Furthermore it should be pointed out that scalars aren't much more > "convertable" than other types in PHP. For example it is possible to That's not true - you can convert int to string, string to int, int to bool, float to bool, etc. Most of these work implicitly - e.g. you can do if($integer) and integer becomes bool. You can do "foo".$integer. You can not have $integer->fileName() and have integer become some object that has filename. > cast pretty much any value into an array (including scalars), yet nobody > is arguing that "array" typed parameters should accept integers as That's because array is not a scalar type. See https://github.com/php/php-langspec/blob/master/spec/05-types.md#scalar-types Try is_scalar([]). Array is a collection type. Its behavior is different from scalars and is more like objects (in fact, if it weren't for BC, it should have been behaving exactly like objects and be just an object type, but that ship has sailed). Also, there's no implicit conversion from scalars to arrays. There's an explicit one but that's different because explicit conversion is always more powerful since it can assume you know what you're doing if you asked to convert, so it should try harder. > input. PHP in general is very liberal with type conversions, this is not > specific to scalars. It *is* specific to scalars - PHP is very liberal with implicit type conversions of scalar types, but the only conversion you can do between non-scalar types are degraded ones like object->array and array->stdClass but even those are only for explicit cast - there are no implicit casts between non-scalar types at all. That makes sense because the semantic of non-scalar types leaves no place for implicit cast - you can not just conjure a SplFileInfo out of object of another class, it's too complex for that. There's a principal difference between scalars and complex types in this regard. > By "vocal community" I'm referring to people who state an opinion on > this topic in a non-internals discussion. The scalar typehinting Conveniently, there's no way to verify this claim. Not that random assembly of reddit commenters is a representative group of anything but a random assembly of reddit commenters. > of having strict type declarations. In various OTR conversations this > was also by far the most common opinion I heard. So, you talk to people that think like you and share your opinion. That must mean you're right or they are a majority of all PHP community? > 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. That depends on the purpose of your analysis. If your analysis is to ensure the code never fails, type analysis would achieve very little. What use would it be to know something is integer if you're taking square root of it? You'd also need to know if it's not negative. And if you're talking about bank balance withdrawal you'd also need to know it's less than the current balance. And so on. You can not prove the code works just by looking at types, especially shallow types like PHP has. If your analysis, however, is the tool to ensure you didn't make obvious mistakes - like returning an HTML page and thinking it's a number - weak typing won't prevent anybody from discovering that. Moreover, if your analysis is intended to help the optimizations - i.e. after this point this variable is a known integer so I can drop all IS_OBJECT checks and just add it to another integer - it would work too. The only situation it wouldn't work is when you expect types to do something types can't do anyway. > E.g. if even something obviously wrong like passing "foobar" to a > boolean argument cannot be detected as incorrect code (because it would Why it's obviously wrong? There are many uses cases that passing non-empty string to a boolean context is completely fine. For example: $response = get_response(); if($response) { ok(); do_stuff_with($response); } else { error(); } It's completely fine and idiomatic PHP, why wouldn't you want to accept it? > be accepted by PHP), then I don't think doing type analysis would have > any value. That's wrong, as I outlined above there are many cases where it could be useful, so the approach of "do it my way or all is lost" is completely unwarranted. > 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 If "abc" is not a valid input for your logic, you'd get a runtime error in any case. > Hack is very similar to PHP. That's a weird case of logic inversion. You start with a claim that "Hack is very similar to PHP", then you proceed to show a part of Hack that is not very similar to PHP - namely, strict typing which PHP never had - and then you claim this proves PHP should change. Maybe this just proves Hack is not as similar to PHP as you previously thought? > If something works for Hack it is likely to > also work well for PHP. Hack was written for one use case and its usage now is a tiny fraction of PHP usage. We have no idea how anything Hack does would work on the scale (both time and user-base wise) of PHP. Maybe it would work, maybe it wouldn't. Claiming just because people designing Hack thought something is a good idea automatically makes it a good idea for PHP is completely baseless. > 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 It is derived, that is true. But where it departs from PHP, there we must be careful. Their derivation does not automatically makes PHP their follower. > Hack is a nice playground for new PHP features and we should be > incorporating the parts that turned out to be useful. For that, we need first to determine they are useful for PHP, not just claim "Hack has it, so we must have it too". Especially when we talk about the features which go contrary to the very principles on which PHP is built. Maybe these principles do not work for you, maybe you'd prefer a language with strict typing and more powerful type inference. That's fine, there are languages for that. But when we're talking about making PHP a strict-typed language, it's a different story and "other boys do that" is not going to be a good argument. > correctness we allow only the specified type. I prefer correctness over > convenience, but I understand that others have different opinions on this. When you say it's your preference, I completely understand you. Everybody has their preferences and styles, some prefer more strict languages, some prefer more relaxed one, some choose these and those depending on context. But if we talk in terms of "majority", "useless without it", etc. then there's much bigger disagreement than just preferences. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
