Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1E54E93F-8CE1-469F-BE1F-DD2F1DF76E39@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me>
	<B0C5801F-7D46-4CB0-9B2E-AF18C44DAF14@ajf.me>
	<CA+9eiLtPVoDYT71fYrZfxPk6a_m7ErFd2w8UBvu9ZeTEbnm4kA@mail.gmail.com>
	<1E54E93F-8CE1-469F-BE1F-DD2F1DF76E39@ajf.me>
Date: Mon, 2 Feb 2015 13:24:46 +0400
Message-ID: <CA+9eiLv3YUdvvo7NbkMOoJEb4eVUyoHEYzoAPweJp3FXVfFNMQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11339f8a7f3ca4050e1786cf
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: dmitry@zend.com (Dmitry Stogov)

--001a11339f8a7f3ca4050e1786cf
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 2, 2015 at 11:41 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Dmitry,
>
> > On 2 Feb 2015, at 07:02, Dmitry Stogov <dmitry@zend.com> wrote:
> >
> > As I already told, in my opinion, version 0.1 was the perfect solution
> that
> > fit into PHP semantic very well.
>
> I don't like the original. Weak types work to a degree, but they don't
> fulfill the use case of a lot of developers, and consequently the RFC
> wasn't too popular outside internals.
>

I sent a separate email to collect use-cases for strict typing. Please,
answer there.


>
> > declare(strict_types=1); - is really weird solution.
>
> It is unusual, that is true. But it has some benefits.
>
> > It changes type hinting behavior per file scope, so, just to try strict
> > type hinting in a big project, people will have to change every single
> PHP
> > file.
> > From the RFC text, I didn't completely understand, if declare() affects
> > call site or declaration.ans
>
> Ah, my bad. It affects function calls and return statements within the
> declare block, or remainder of the file if there's no declare block. So
> parameter types are checked using the mode chosen by the calling code,
> while return types are checked using the mode chosen by the called code.
>

not your bad, it's exactly what I read, I just couldn't believe that.


>
> > Will we able to call the same function using weak
> > type hinting from on file and with strict from the other?
>
> Yes, for the parameter type hints anyway. That means that strict and weak
> code is interoperable without enforcing a model on each other.
>

At first I thought, this is ugly solution. Now I'm not completely sure.


>
> > "The strict type checking mode also affects extension and built-in PHP
> > functions", sin(1) - error !!!
>
> That particular case is probably unpopular - although strict type hinting
> for ints and floats can prevent nastier errors later (float out of int
> range, or silent loss of precision from int to float).
>

I see, but this would require declare(strict_types=1) everywhere that would
turn PHP into Java.


> Strict type hinting is not suitable for PHP by definition (as a weakly
> > typed language), however, I see, it may be useful in some cases.
> > I would prefer to have "weak" types at first, then think about
> introducing
> > ability to switch to "strict" type hinting in context of use-cases.
>
> That'd be possible, but I fear that we'd just end up with weak typing only
> and no strict solution. Regardless of its merits, a large portion of the
> community is in favour of a strictly-typed solution. There are also a lot
> of people who are in favour of weak typing. So, this RFC tries to make a
> compromise.
>

I see, but I afraid that compromise is worse than one or the other.

Thanks. Dmitry.


>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>

--001a11339f8a7f3ca4050e1786cf--