Re: [RFC][Vote] Return Types

> On 5 Nov 2014, at 11:53, Dmitry Stogov <dmitry@zend.com> wrote: > > Hi Levi, > > The patch is here > https://gist.github.com/dstogov/8deb8b17e41c1a5abf88 > > I improved memory consumption and unified return type-hinting error > behavior with existing argument type-hinting. > The main semantic must be unchanged. This sounds good. > I also removed part of Reflection changes. I think we should remove even > more and later introduce similar APIs for both argument and return > type-hinting at once. I'd rather not go through 3 weeks of internals to get in ReflectionType for parameters. I'd imagine adding ->getReflectionType for parameters would be fairly uncontroversial, can we just do that now? > Working on the patch I found few problems. > > 1) Return type-hinting for generators in existing state is useless. We may > use it for checking "yield" value instead of "returned" or just disable it > for now. I don't think it's useless. You can require a function to be a generator. Is that bad? If we added generics in future, we could then type the yielded type, e.g. Generator<int> maybe? > 2) "Covariant" return type check is really problematic. It delays class > binding to run-time, and requires all classes, used in hints, to be loaded.. The former sounds like a problem, but doesn't inheritance require these classes to be loaded anyway? Do we always load the class in the hint? We could perhaps only do it for inheritance checks? > I would prefer to simplify this by using "Invariant" return types (similar > to arguments) and checking just class names (without their loading). This is problematic, it'd stop classes from changing return types to subclasses in inheritance, which would make them less useful. -- Andrea Faulds http://ajf.me/