On 4 November 2014 12:17, Robert Stoll <p...@tutteli.ch> wrote: > > > -----Ursprüngliche Nachricht----- > > Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im > Auftrag von Chris Wright > > Gesendet: Dienstag, 4. November 2014 12:51 > > An: Andrea Faulds > > Cc: Stas Malyshev; Robert Stoll; PHP Internals > > Betreff: Re: AW: [PHP-DEV] Types on the right or on the left > > > > On 4 November 2014 10:32, Andrea Faulds <a...@ajf.me> wrote: > > > > > > > > > On 4 Nov 2014, at 08:51, Stas Malyshev <smalys...@sugarcrm.com> > wrote: > > > > > > > > I agree, this is not a very good situation. It would be much better > > > > to take a systematic approach to this, but this is impossible since > > > > there is no systematic approach to strict typing in PHP, just some > > > > pieces here and there. I think this is not right, but obviously many > > > > people here disagree and are happy to have the inconsistent syntax. > > > > I don't see why "public Foo function bar()" would be so much worse > > > > than "public function > > > > bar() : Foo" but for some reason this possibility wasn't even > > > > considered as far as I can see. > > > > > I thought it was inconsistent, but after discussions on StackOverflow, I > > > don't think it actually is. Return types describe the return type of a > > > function, not the type of a function. So there's no reason they have > > > to go before the function name like parameter types do. > > > > > > > > So, in a sentence: > > > > In PHP, input types go on the left and output types go on the right. > > > > This sounds like a convention that could be established and followed, > and no-one could reasonably call it inconsistent if it > > was adhered to. > > That is an interesting thought. Yet, where would you put the type of an > out parameter then?
I wouldn't, because this wouldn't ever make sense in PHP. I'm not a fan of out parameters in general in PHP, but enforcing the output type of a variable can't ever make sense in PHP from an implementation perspective without sacrificing some dynamic features that won't ever disappear - I'm sure it could be done, but not without a huge and unacceptable performance penalty. > Nevertheless, you could phrase your convention differently so it makes > more sense and well.. in the end we can do whatever we like in PHP and > call it xy-convention and the user will have to pick it up and learn it > (quite similar to array functions where usually the first argument is array > and suddenly it is not the first parameter as with array_key_exists, > array_map or array_search). Sure it is no big deal, the user should be able > to pick up the convention quickly but we could facilitate it, make it > easier for the user, more intuitive, in order that the user has a steeper > learning curve. And the time to decide what direction PHP should take is > now with PHP 7. > Please remember that PHP 7 is not the last major version of PHP. The things we do now are set in stone, but they do not mean that something else cannot be done in the future to build on top of them, as long as they do not conflict. I guess it's worth noting that my *personal* opinion is that I'd also rather have the function return type declaration on the left (I'd also like to drop the requirement for the "function" keyword in method declarations), but since there are a number of reasons why this no longer makes sense, and will never make sense again, I didn't hesitate to vote in favour of the current proposal because more than anything else I think the feature is what is important, and I know how much work has been put in to ensuring that the proposal satisfies as many concerns as possible. There will never be a better proposal than this.
