Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83795
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFV9VhC=5MTr+iXxJniLg1pcyLVbv7gZAFfPiYu1soh2A@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>
	<CAAyV7nFV9VhC=5MTr+iXxJniLg1pcyLVbv7gZAFfPiYu1soh2A@mail.gmail.com>
Date: Wed, 25 Feb 2015 19:13:44 +0400
Message-ID: <CA+9eiLuhu1mxaFeuFbEk67Hdx1KxwzG287W7VghwH0kio250SQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86d990d7715c050feb1432
Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: dmitry@zend.com (Dmitry Stogov)

--047d7b86d990d7715c050feb1432
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 25, 2015 at 6:03 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> 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.
>

It's also a reason why others may vote against the whole and we will get
nothing.


>
> I'd rather keep the vote about one thing, and one thing only.
>

I got you. All or nothing :)


>
> > 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.
>

I post the links to the important changes above. Even JITed code will have
to implement these additional checks in run-time.


> 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.
>

It's not so simple, because you don't know the function at compile-time.


>
> >
> > - 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.
>

Not all resources may be replaced with objects.


> > - 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);
>

right. but this is a smaller break.


> 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).
>

this is your opinion. I have another. I don't know opinion of others.
Why not to 50/50 voting. If you don't do it, may be I should do.

Thanks. Dmitry.


>
> Anthony
>

--047d7b86d990d7715c050feb1432--