> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > > > Mixing both, having some types on the left and others on the right, > > seems like another inconsistency in the language > > > design to me. > > > > These inconsistencies exist for two reasons: > > > > - Opposition to doing it the other way > > - Hack already doing it this way > > > > I don’t think `function void foo();` will happen, since that’s been > > previously rejected as it breaks gripping for “function foo”. Similarly, I > > don’t think `public $foo: Foo;` will happen, given Hack does it as `public > > Foo $foo;`. > > I agree with Andrea. > > There are people who dislike syntax, and/or thinks PHP missing check(i.e. > array format, etc). These people should request DbC. > DbC is more powerful than simple type checks and have no performance > penalty in production. (I'm not saying type hinting is > useless. I'll use it where it is appropriate, too.)
+1. I have been reading these discussions about type hinting for years. Every time, people try to bring strong typing through various artefacts, because they don't understand the benefits of loose typing. Some years ago, their model was java, today, it is a combination of java and Hack. Unfortunately, the RFC on return types was approved. It was just a question of time, with all these people pushing during years. Half-backed, short-term solution, attractive at first sight but bringing more problems than it solves... It will probably have catastrophic implications on the 'REAL' solutions someone may propose in the future. >From the beginning, I think that DbC based on phpdoc annotations, with >controlled type conversion (which ones are valid, which ones are not) and >switched on/off by an INI parameter would be the best solution to provide the >restrictions and checks developers are asking for. Unfortunately, half-backed, >short-term solutions, like return types and type hinting, will make proposing >such a solution harder, as we will need to keep BC. It will even be an >argument to fight against a better solution. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
