Re: Return Type Hinting for Methods RFC

On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote: > Hi! > >> And in those cases, they would continue to use the keyword "function" >> and be considered unknown as they are today. > > Taking the most common case and ignoring it and saying "ok, then don't use it" > is not a good way to design a feature in a general-purpose language that would be used by literally > millions. The feature isn't designed around "only those who use it." In fact, as per the RFC, the keyword "function" will be used to serve as a mixed return type. There are cases where I don't want to type hint my return value from a method and will continue to use this. All scalar values will be forced to use this way anyway. Namespaces, interfaces, abstracts, closures, traits..... the list goes on with features that were built to give developers additional tools to use. Are any of them required to use? No. It's general purpose - just like the feature offered here. How many features are built into PHP that are meant to force a user to use it, or even break BC? Why would you suggest this is doing any different? Can you provide an example where this feature is doing that? > >> I don't compare PHP to ruby, python or JavaScript. Do I suggest >> features that I find useful in other languages like C# or Java or even >> in any of the ones you listed? Absolutely. > > C# and Java, again, are fully statically typed compiled languages. PHP is not. That means that > the benefits of strict type system that are available to programmers in C# or Java will not be > available to PHP programmers, while the downsides of it (and inflexibility that such system leads > to) will still be there and will actually be multiplied by the fact that you wouldn't know > about the problem with your typing system until your application starts crashing. Are you saying parameter type hinting isn't in PHP? > >> add overhead, just as parameters do (arguably more). But it is a >> feature that is very valuable to many. Those who wish not to use it >> can continue to do so. > > Sorry, again, "don't use it" is not a valid response for a core feature in a > widely used language. It would be OK for a PECL module - if you don't like mongoDB, don't > use it, nobody objects to having mongodb extension because it is not fit for some scenarios. > However, designing core language features that change the nature of the language - making it from > non-typed to strictly typed - have bigger requirements. You can not just "not use" core > feature - because others will be using it and you'd have to leave with it and interface with > their code. Sorry, again, look at what I said above. Namespaces, interfaces, abstracts, closures, traits, parameter type hints, even classes are core features that users aren't forced to use. Please tell me what makes them different. It is an optional feature - just like all those I listed. If others are using it, that's the point. Can you walk into existing code that you must interface with today that has a type hinted parameter and decide not to use it? No. Why? Because the company/developer who developed that solution made the decision that it was a feature they found useful. What you're suggesting is that we design features around those who do not want to use it. > >> Don't forget that while return checks are runtime, interface >> definition and implementations are compile time. > > Nothing is compile time in PHP, PHP has no compile time (at least if we don't consider > projects like HipHop, which is totally irrelevant here) like C# or Java does. That's not how > PHP code works. In C# and Java, you can take the code and know in advance the type of any piece of > data in any place (maybe not precisely but at least base type). In PHP, you can not. So Java's bytecode, which requires a VM (interpreter), isn't comparable to PHP's "compile"? Are you saying compile is only when code is converted into machine code? Moving PHP code through a lexical analyzer, syntax parser, intermediate code generator/opcode isn't a form of compilation? Considering the verification of interfaces is done during the syntax parser, in a file called zend_compile.c, before the code is actually executed, I'm pretty comfortable calling this transformation "compiled." > >> Because null is a standard already set by parameter type hints. I do > > not want to sway away from that as it works well. It is common for > > I'm not sure what you're talking about as a "standard". Yes, input > parameters strict typing allows nulls because it was another frequently used scenario that strict > typing does not support. Fortunately, it could be fit into "default value" syntax, even > though it doesn't really means that (so we actually have a syntax that means two different > things now, not a great idea). But with return types and value strict types (which would inevitably > be asked for next) it wouldn't be that easy. There's no syntax for "default return > value" and the case of returning false - one of the most common - can not be covered. And, on > top of that, I still do not see any benefit of it as you'd still have to check the return value > anyway! public function blah(SomeClass $class = null) { if ($class) { // code here } } What I'm calling a "standard" is something already in the language. If I had written this to allow "false" to be returned instead of null, the complaints would be much greater. Why? Because we're used to the type hinting allowing that. I want to make it clear that my goal with this RFC *isn't* to offer a compile time feature for the sake of having it. Because PHP is interpreted and we have our on minds, we can make decisions such as the frequently used scenario you mentioned above. If the general consensus is that you *must* return the type declared, then I'm game for it. In fact, code execution would actually be faster. But what will end up happening is this: public array getArray() { // Uh oh, I'll have to return an empty array return array(); } $array_value = $obj->getArray(); if (!empty($array_value)) This is why I decided on the null option. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227