Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93822
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <f25ac588-7fcb-2b64-4a55-1896ddb9f24e@fleshgrinder.com>
References: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com>
 <CA+kxMuTWzqDhGqiiuLjabK7eMXev8LSrvRx48+PrzO7DxYNpBA@mail.gmail.com>
 <a6f8fc9f-be2f-0f30-b0d0-8d5f34cca092@fleshgrinder.com> <CADyq6sL72Xy9EzTE1weUbf5B1cXv75zNRy6Z6PvsQ5sB-mf9rw@mail.gmail.com>
 <f25ac588-7fcb-2b64-4a55-1896ddb9f24e@fleshgrinder.com>
Date: Sun, 5 Jun 2016 22:26:08 +0200
Message-ID: <CADyq6sJbEUXmhZyrWQBtwUgJsNgQW7sUwBsyT9q6+Cre_oCGwg@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Cc: Dan Ackroyd <danack@basereality.com>
Content-Type: multipart/alternative; boundary=001a114b310049d59805348dc529
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
From: ocramius@gmail.com (Marco Pivetta)

--001a114b310049d59805348dc529
Content-Type: text/plain; charset=UTF-8

Hey Richard,

On 4 June 2016 at 18:41, Fleshgrinder <php@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/

--001a114b310049d59805348dc529--