Hey Richard,
On 4 June 2016 at 18:41, Fleshgrinder <p...@fleshgrinder.com> wrote:
> 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:
>
Good point, probably not something you'd want to happen to pre-existing
code.
> > 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.
>
I may have misunderstood the feature at first. By thinking about other
languages with typeof support, I assumed this RFC was about a
machine-friendly representation of a variable.
I'd be "okay" with this if it was documented as "human friendly string
representation of a variable's content", or something similar. It should be
made 100% crystal clear that it is not for machine-consumption though.
Returning a string will cause developers to rely on it for other things
(besides meaningful exception messages), and that should be discouraged
behavior.
I also back Sara's concern, which is that a function like this one can be
implemented, tested, improved and upgraded in userland, without the need
for it to exist in core.
I'd rather do a `composer require some-debug-utils-orga/type-of` than
relying on another core function, which (and this will happen anyway), if
bugged, cannot get fixes without a complete php installation upgrade.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
