Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99254
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.192.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuSgz5EEhfO6dgTtCL=TiYw2ZraH88xKb17Vj9yFgdzr2Q@mail.gmail.com>
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> <CA+kxMuSgz5EEhfO6dgTtCL=TiYw2ZraH88xKb17Vj9yFgdzr2Q@mail.gmail.com>
Date: Tue, 30 May 2017 08:24:53 +0200
Message-ID: <CADqTB_grvLXm9RrCdcKhJTA_J2+sG3WXNdzeB4jnteneNCxhQQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>, Niklas Keller <me@kelunik.com>
Content-Type: multipart/alternative; boundary="f403045cc8a2a7e8cd0550b7dc9d"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: rasmus@mindplay.dk (Rasmus Schultz)

--f403045cc8a2a7e8cd0550b7dc9d
Content-Type: text/plain; charset="UTF-8"

> The type widening RFC makes it easier to move to parameter types for
existing libraries.

I'm curious to see how you'll set the version constraint in your
composer.json file.

After adding a scalar type-hint to an interface, which is a breaking change
in 7.0 and 7.1, but a non-breaking change in 7.2, is the new version of
your package a major or minor release?

If you release it as minor, you'll need a PHP version constraint like
"^5.5, ^7.2", but excluding 7.0-7.1 In that way is itself a breaking
change, so likely your only practical move is to release (and commit to
maintain!) both major and minor versions, which doesn't sound easy at all.


On May 29, 2017 00:53, "Dan Ackroyd" <danack@basereality.com> wrote:

> On 28 May 2017 at 14:25, Rasmus Schultz <rasmus@mindplay.dk> wrote:
> >
> > To me, that's a setback that leads to harder-to-debug errors, and
> increases
> > learning-curve.
>
> Everything is a trade-off. The type widening RFC makes it easier to
> move to parameter types for existing libraries.
>
> While I can see what you mean about how it could lead to more
> accidental errors, for me at least, it would be actually quite hard to
> not notice those errors in the code.
>
> First, when people are programming against the interface rather than
> the implementation, that type of mistake is much easier to spot.
>
> function foo(Repository $repo) {
>     $repo->save(new stdClass());
>     // The above line is marked as an error in any decent IDE
>     // or code analysis tool.
> }
>
> Second, accidentally dropping the type from the parameter is also an
> easy mistake to spot.
>
> class UserRepository implements Repository {
>     public function save($item) {
>         // When inside this function the programmer has no idea
>         // what type item is. Any call to a method or property will
>         // be marked as a potential error either by an IDE, static
>         // analysis tool, or just the programmer realising
>         // "that parameter has no type".
>     }
> }
>
> So, to me (and possibly others who voted for the RFC) the ability to
> add types to interfaces without breaking implementing library is a
> good trade-off.
>
> And yes, the type system in PHP could definitely be improved. Perhaps
> you could propose an RFC? I suspect it might need to target PHP 8. I'm
> personally hoping that some form of the union type RFC could return,
> though possibly in a more general form.
>
> cheers
> Dan
> Ack
>

--f403045cc8a2a7e8cd0550b7dc9d--