Re: [RFC][Vote] Return Types

From: 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/

« previous php.internals (#78760) next »