On Wed, Jun 26, 2013 at 4:21 PM, Patrick ALLAERT <patrickalla...@php.net>wrote:
> 2013/6/26 Julien Pauli <jpa...@php.net>: > > But what Sherif said proves as well the limits of the idea. PHP is not > > strongly typed. So each check, should it be type hinting or return type > > hinting, has to be done at runtime , which is bad for performances. > > It doesn't mean you have to use it, just that it might be used instead > of implementing a manual check in every function/method callers, or, > alternatively, in the function/method itself. > Being done at runtime by the language will for sure not be worst for > performance than doing it manually in pure PHP. > > > Not talking about the type juggling which could lead the programmer as > > shooting himself. > > Sure! Hence why *if* this is taken into account, it should really be > done the same way as it is done for input parameter hinting, to not > introduce what we already don't want there. > > I think that the return typehints a bit easier topic than the input type hinting(for scalars), because that affects the caller, while return type hinting is more contained: you write the function, you put the return typehint there, if the method tries to return something else, then your code is at fault. So even if we would allow return typehints for scalars that would only affects those functions where the developer opts-in. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
