Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93786
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.42 cause and error)
MIME-Version: 1.0
In-Reply-To: <94009625-535b-d937-21b6-b454f942a82d@gmail.com>
References: <d9847a18-49c0-d2d0-db4e-e0d6e6685ba0@fleshgrinder.com>
 <CAESVnVoSbkT=u+agkx9mn+aqsyGv9qOo27tdbkje4qpJ2S=gFg@mail.gmail.com>
 <CADqTB_jDbkmbYEoyX-SE69ZSUu1-3aWRrJ9pYdE4vGn9acmegg@mail.gmail.com> <94009625-535b-d937-21b6-b454f942a82d@gmail.com>
Date: Sat, 4 Jun 2016 23:25:32 +0200
Message-ID: <CADqTB_irWb2X53L3C1ppNhxUqXL4z2+sxq7bXuWTqkYNDGZYQw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11457d64b6f52a05347a7afc
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a11457d64b6f52a05347a7afc
Content-Type: text/plain; charset=UTF-8

> I don't think we need a core function that almost exactly duplicates the working
of existing function but with a slight tweak. I do not think it is a good
idea to do such things, it only produces more confusion.

I strongly disagree.

The old function is actively causing confusion - the reported type-names
aren't even inconsistent with scalar type-hints, and then you have to go
and read the manual with some explanation about historical reasons why the
function doesn't work like you'd expect.

PHP is infamous for these surprise moments.

I think that gettype() should be deprecated in favor of a new function that
actually makes sense.

I think that deprecating and fixing things is long-term less confusing than
documenting your way around legacy functions that produce surprising and
confusing results.

IMO this is a clear improvement which *removes* a source of confusion.


On Sat, Jun 4, 2016 at 10:38 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> >> My number one issue with this PR is that it's all PHP code.  There's
> nothing
> > in here that couldn't be done as a composer installable library
> >
> > It's a valid point, but not really a good argument against having it -
> the
> > same could after all be said about a lot of PHP functions.
>
> Many of those were introduced when we didn't have good ecosystem for
> libraries, and whatever is baked into PHP binary is all you got to work
> with. Not the case anymore. Many others were introduced because it was
> hard to do it in PHP (no access to some internals, or slow, or required
> things that code break between versions). Not the case here either.
>
> Also, there's a difference between core having 20 functions and adding
> 21st that is doing something new, and core having 200 functions and
> adding 201st that does exactly like one of the existing ones but
> slightly different (slightly enough so you'd have to consult the manual
> now to see why you used each of them in each context).
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>

--001a11457d64b6f52a05347a7afc--