Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99225
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
To: internals@lists.php.net
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
 <CANUQDCjpjz8Wret1D6q9wb8rfBH4Xqc4uDqLTtuptkUdesUK4g@mail.gmail.com>
 <CADqTB_gbhw+pr+8dpkwdFwRTjiY4pk6fyeTnLUv72fBjTpArZA@mail.gmail.com>
 <CA+kxMuS=xBVQdyObpU2yK1jtr+3=JmAPJK-DaRKCZdCZRCfp2w@mail.gmail.com>
 <CADqTB_hs85GU63D5pB7ArHBhJ=0CK_aUYtPiOvokn4OeyFXTRA@mail.gmail.com>
 <CANUQDChF3BVkBUH7BOjXwNQapvzBQHwExZMQbeRYpn44jcCXfA@mail.gmail.com>
 <CADqTB_gc9BJnhL7fE-w51dYX760GSGsu6Vhc2d=DStLWRKXLRA@mail.gmail.com>
 <8de6a2ef-9602-e489-f19c-001005626b87@gmail.com>
 <CALtMV+PBbVjue=26-=W5K7PwHA=hjjRQqKKaxq-KJ6W2doDkwA@mail.gmail.com>
Message-ID: <e6806353-0779-6b75-bd16-6c44bb030302@gmail.com>
Date: Mon, 29 May 2017 11:02:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CALtMV+PBbVjue=26-=W5K7PwHA=hjjRQqKKaxq-KJ6W2doDkwA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 28/05/2017 18:06, Aidan Woods wrote:
> So, if I understand everything here correctly
>
> ```
> interface Foo
> {
>    public function bar(Boo $Boo);
> }
> ```
>
> and
>
> ```
> interface Foo
> {
>    /*
>     * @param $Boo, pretty please accept type Boo here
>     */
>    public function bar($Boo);
> }
> ```
>
> will be equivalent in 7.2? :(

No, what's being proposed is that this will be allowed:

interface Foo
{
   public function bar(Boo $Boo);
}

class Bar implements Foo
{
    public function bar($Boo) { ... }
}

Whereas currently, the class would have to look like this:

class Bar implements Foo
{
    public function bar(Boo $Boo) { ... }
}

An interface's job is to provide guarantees to calling code about where 
and how an object can be used. It doesn't place any limits on what 
*else* the class can do - class Bar might have extra methods, public 
properties, be written in a completely different style, etc. Accepting 
extra types *as well as* the one specified in the interface is in the 
same category: the class is doing *more than* the interface, and that's 
none of the interface's business.

I think some of the examples here are approaching interfaces as a 
broader contract, that allows a library author to say "you must 
implement the library this way". It's similar to the debate about 
whether strict type hints should be the choice of the caller or the 
callee. If you treat each module of the program as a black box, then all 
that matters is the guarantees of what's acceptable, which type hints 
and interfaces provide; but if you want more control over *how* somebody 
meets those guarantees, then I can see that this RFC, and the 
caller-selected type hint modes, would feel like a step in the wrong 
direction.

Regards,

-- 
Rowan Collins
[IMSoP]