Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120596
MIME-Version: 1.0
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
 <648AAE1D.9070805@adviesenzo.nl> <CAAKU0uk=tKzzaGRJAF+7WaT-3CbCwjJbHFbc4WCqCRK_9+OOgw@mail.gmail.com>
 <648B30B5.50705@adviesenzo.nl>
In-Reply-To: <648B30B5.50705@adviesenzo.nl>
Date: Thu, 15 Jun 2023 13:01:14 -0300
Message-ID: <CADK1yX+RoEk5FS6AeZzrKAHNGw1PQjN4JtOvz43f39CSDeKZiw@mail.gmail.com>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000b2493705fe2d2fab"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: deleugyn@gmail.com (Deleu)

--000000000000b2493705fe2d2fab
Content-Type: text/plain; charset="UTF-8"

>
> I still believe this information should be added to the RFC as the risk
> of adding new methods to an interface which collide with existing
> methods in implementations of that interface is very real, though I
> agree with Deleu that this BC impact is not so much of the RFC, but of
> what can happen once the RFC would be accepted.
>
> While I can understand the tendency to defer this question to "that's an
> issue for userland when userland adds new methods to existing
> interfaces" (or PHP itself if new methods would be added to PHP native
> interfaces), I don't think that's fair as this RFC is the one which
> opens the door to that possibility.
>
> Smile,
> Juliette
>

Adding a new method to an existing interface is already a BC break today
and requires a major version bump, otherwise implementers of the interface
will get a fatal error because they're missing implementing all methods of
an interface. We can call this a "Userland BC Path" (how a userland can
make a BC to other users). This RFC doesn't open this door, it actually
creates a path which makes this Userland BC Path less "damaging". If an
interface provider adds a new method to an interface (already a BC Break),
but does so by adding a default implementation, then such a change will
break less code than just adding a method without a default implementation
because only code that already had the exact same method name would now
break.

One can argue that this change might make it so that users start
considering adding methods with default implementation as
not-so-much-a-bc-break and do so without bumping a major version, in which
case this RFC could be said to "open the door for some users to start
introducing BC-breaks without bumping major version" because they consider
it a much smaller BC break, but it can't be said to open the possibility.

Does this make sense?

-- 
Marco Deleu

--000000000000b2493705fe2d2fab--