2014-07-14 14:19 GMT+03:00 Alain Williams <a...@phcomp.co.uk>: > On Mon, Jul 14, 2014 at 01:09:42PM +0300, Arvids Godjuks wrote: > > > PHP does not need a type hinting system forces you to first make a > > No one is 'forcing' anything. You use it where it is appropriate; that > does not > mean everywhere - there are plenty of places where I would not want to use > it. >
The trend I see in the messages is that people tend to drift to a restrictive model of type hints - you pass the wrong type and get an E_RECOVERABLE_ERROR, or add the warning to E_STRICT level (now I don't get strict warnings at all) or something else comes up. People forget the KISS, people forget that someone actually has to implement all that and it's not easy by far. All that additional stuff is going to take a lot of development time, will slow down the engine (especially if we do array/object casts - what if someone passes a big object collection to an array parameter or vice-verse?). It just feels wrong and unnecessary. If you feel PHP does not provide you with enough strictness - switch the language. > > > P.S. And on that "var integer $variable" in methods/functions. People, > when > > you have internal functions returning null|array, bool|array and so on - > > this is pointless. > > In that case you would declare "var $variable" to receive the value from > such a function. > > The point of the use of "var" is to ensure that variables are declared > before use. > There is a whole set of errors that can be eliminated by this -- typeos > where > you assign to the 'wrong' variable. > > http://stackoverflow.com/questions/8023959/why-use-strict-and-warnings > > "var integer $variable" has a use where do you know they type, eg you got > it > from the typed function arguments. > > As with all of this: if you don't find it then don't use it, leave it for > those > who do understand the benefits. And more pointless boilerplate code to write. If I need a variable initialized - I just initialize it: $var = 0; Any modern IDE and even some editors will show you uninitialized or/and unused variables. Renaming is for "Refactor -> Rename". PHP team has enough on it's plate than writing a static analyzer into the code parser, implementing over-complicated RFC's and so on. People on this list have to start to think practically. Previous RFC's for the type hints didn't got through because of people trying to get all the things into them, agreeing to disagree and authors just got fed up and probably (I guess here) when realizing into how big and complicated a peace of work the RFC became just bailed out with "FUA" (I definitely would do exactly that, of course never stating that directly in public, just would declare the dropping of the RFC - but it would be what I felt internally). So my proposal is to go the KISS way and make baby steps, see what fruit it will spawn. Do the basic param hints, use leftover time to pick up the "Return type hints" RFC. See how it all pans out in the real world and then do improvements, if necessary. Basic type hints for scalar types with type casting, don't touch array and object type hints, add a E_TYPEHINT_CAST_WARNING warning level so you can generate them when data loss occurs. And don't change explicit casting. Just to show what I mean: function test(int $param) { }; // $_GET['id'] === '123a' test($_GET['id']); // Get a E_TYPEHINT_CAST_WARNING test((int)$_GET['id']) // Everything works like a charm The last workflow, when I do an explicit cast, is kind'a what many are used to with the PHP casting system. The difference with type hint is that I can check where I forgot to make the explicit cast and PHP Engine, in the future, can make use of explicit cast being made and optimize the $param usage in the function as an integer. This also gives the ability to update the code peace by peace and not suffer from tons of warnings/errors that are generated by typehint casts that loose data that are disabled only with some other type of errors/warnings that I would like to stay enabled (I run my code in E_ALL | E_STRICT on production with display_errors = Off - anything that get's into logs is being fixed ASAP).
