Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83789
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLuuH7v4Vvf8iDzvh=vho9mdPUpvSVHwuP6+JdNVkqLS9A@mail.gmail.com>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
	<CAAyV7nE+JJPr4iRiFfJg74UVZ_c6HieOmpPQWe6zwnY==m7Zhw@mail.gmail.com>
	<CAAyV7nGOh7FgkbkPGwALmU4SDOs=LvkijAPJeNcG3qrMo7-z-Q@mail.gmail.com>
	<CAAyV7nFfzaw=M0En4_3Lt5MYQ7H+ePCzFOuM4wndehxJER7NXQ@mail.gmail.com>
	<CA+9eiLuuH7v4Vvf8iDzvh=vho9mdPUpvSVHwuP6+JdNVkqLS9A@mail.gmail.com>
Date: Wed, 25 Feb 2015 10:03:09 -0500
Message-ID: <CAAyV7nFV9VhC=5MTr+iXxJniLg1pcyLVbv7gZAFfPiYu1soh2A@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: ircmaxell@gmail.com (Anthony Ferrara)

Dmitry,

On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> Hi Anthony,
>
> Few notes:
>
> - first of all, it would be great to split the voting questions: 2/3 -
> implement scalar type hinting + 1/2 - in addition add strict type hinting as

I've mentioned this a few times, but I disagree with that concept. I
believe RFCs should fully describe a feature and should be voted on in
whole.

Additionally, it presents a problem when it comes to voting. What if a
person wants strict types. And it looks like it's overall going to
pass, but that weak types is winning. What's the best way for them to
vote? No. For the entire proposal.

I'd rather keep the vote about one thing, and one thing only.

> you propose. I think, the concept of run-time declare() switch is not
> designed well. It just affects VM and JITed code in negative way, because in
> each function we will have to handle both options
> https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR3762
> and also set additional flag on each call
> https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR2802

What negative way is that? It's a clearly defined switch, kept in a
clearly defined place.

And considering it's a purely compile time construct, I fail to see
how it could possibly affect either the VM or JITed code in a negative
way.

Heck, if we really wanted to, we could compile a separate
ZEND_DO_FCALL opcode for strict types: ZEND_DO_STRICT_FCALL, which
hard-codes the strict data.

>
> - resource type hint may be useful in the same way as all other types

The problem here is typing on a resource doesn't give you enough
information to be "safe":

function foo(resource $bar): string {
    return fread($bar);
}

foo(mysql_connect(...));

I think a longer-term plan to replace (transparently) resources with
objects would be far more beneficial.

> - it may make sense not to disable bool/int/float/string classes at all. we
> may just don't allow them in type hints. This will break less applications.

It'll still break applications, because you can no longer do:

function foo(String $string) {}

foo(new String);

I think leaving the ability to create a class named "string" while at
the same time removing the ability to type against it is not only
weird, but definitely not something I think we should do (it's just
way to inconsistent).

Anthony