Re: [RFC][Vote] Return Types
| From: | Andrea Faulds | Date: | Thu, 06 Nov 2014 00:26:26 +0000 |
| Subject: | Re: [RFC][Vote] Return Types | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78760@lists.php.net to get a copy of this message | ||
> On 5 Nov 2014, at 22:15, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>
> Hi!
>
>> No, classes are not loaded for type checks, since it would be pointless
>> - if the class is not loaded, you could not have a value of that type,
>> so if the class is not present, the answer is "no".
>>
>>
>> It's not true anymore, with this proposal.
>
> This is not good. The base premise of type checks always was if you
> don't use them, they are basically free - you don't load the classes,
> you don't do any work, until you actually need them, and by then your
> class is supposed to be already loaded, so again it's not costly. But if
> just declaring a type could trigger loading of code, this may
> significantly increase the footprint and loading time for classes that
> have many options but only use some of them at the time.
It shouldn’t need to load any code normally, it’s only if an inheriting class changes the type.
> Also, it is kind of weird that arguments require exact match but return
> types do not. Not that we care for consistency anymore…
Yeah, we should probably have arguments be contravariant or covariant.
I was going to argue that covariance is important, but now that I think about it, the most important
case is just self. If I can have Foo::foo() return a Foo and Bar::foo() return a Bar, with Bar
inheriting from Foo, and this not breaking the invariant type check, I’m happy.
--
Andrea Faulds
http://ajf.me/