On 6/4/2016 6:17 PM, Marco Pivetta wrote: > It would be beneficial to not reduce this to stringly-typed programmer > (again), as Dan mentioned. > > Returning something like a ReflectionType instance (which then implements > __toString) would be much simpler, efficient and easy to use. > > Marco Pivetta >
Hey Marco,
not sure if I like that approach for a procedural function. If we would
want that than it would be better to implement it as a named constructor
of the actual class.
class ReflectionType {
public static function from(mixed $var): ReflectionType;
}
But anyways, it would result in changing the purpose of that class:
> The ReflectionType class reports information about a function's
> return type.
I'd argue that we would need a completely new reflection class to handle
this use case, e.g. ReflectionVariable. However, I cannot see that this
is actually required while looking at the usage patterns of the existing
gettype() function. The goal here is to continue supporting the existing
mode of operation and its usage in userland while updating it to reflect
the current state of the type system. Additionally, pretty much nobody
uses it to determine the type of a variable but merely to include the
resulting string in debug/error messages.
The reflection class approach would mean that even more reflection code
ends up in production code, another thing I consider questionable.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
