Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83864
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Anthony Ferrara'" <ircmaxell@gmail.com>,
	"'Dmitry Stogov'" <dmitry@zend.com>
Cc: <internals@lists.php.net>
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>
In-Reply-To: <CAAyV7nFV9VhC=5MTr+iXxJniLg1pcyLVbv7gZAFfPiYu1soh2A@mail.gmail.com>
Date: Thu, 26 Feb 2015 03:04:14 +0100
Message-ID: <09d901d05168$852e5840$8f8b08c0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQNRCtsuxpDhJkWLwbpkER3sGaOi3AHrYI7jAdlgWoQBRyBzfwIiz2rpAtEwmdWZsLemwA==
Content-Language: fr
Subject: RE: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Anthony Ferrara [mailto:ircmaxell@gmail.com]
>
> 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.

Agreed. IMO, splitting votes is theoretically possible, but not in =
parallel.

Actually, if we had wanted to proceed this way, we should already have =
finished the first vote. Too late now.

I don't know if it was already suggested but, whatever the date each STH =
vote starts, I suggest we synchronize end dates, in an attempt to limit =
side effects.

I don't know it the tool we use can be configured to allow for each user =
to see only his own vote before vote ends, and only global result when =
it is over, but it would probably improve the process a lot.

Regards

Fran=C3=A7ois


>=20
> I'd rather keep the vote about one thing, and one thing only.
>=20
> > 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
>=20
> What negative way is that? It's a clearly defined switch, kept in a
> clearly defined place.
>=20
> 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.
>=20
> 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.
>=20
> >
> > - resource type hint may be useful in the same way as all other =
types
>=20
> The problem here is typing on a resource doesn't give you enough
> information to be "safe":
>=20
> function foo(resource $bar): string {
>     return fread($bar);
> }
>=20
> foo(mysql_connect(...));
>=20
> I think a longer-term plan to replace (transparently) resources with
> objects would be far more beneficial.
>=20
> > - 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.
>=20
> It'll still break applications, because you can no longer do:
>=20
> function foo(String $string) {}
>=20
> foo(new String);
>=20
> 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).
>=20
> Anthony
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php