Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOv67gsRwiR_aR=WJCqfJOeE8rUppuhD64m=sHZA6Vzjf59Diw@mail.gmail.com>
References: <CAOv67gsRwiR_aR=WJCqfJOeE8rUppuhD64m=sHZA6Vzjf59Diw@mail.gmail.com>
Date: Wed, 1 Mar 2017 08:15:58 +0100
Message-ID: <CADyq6sKbCG59CoZ9FFN6jRD7pdQk_NA8AzgOhVFvraaGVDAw0Q@mail.gmail.com>
To: Wes <netmo.php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c19014ea496310549a615e0
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Allow abstract function override
From: ocramius@gmail.com (Marco Pivetta)

--94eb2c19014ea496310549a615e0
Content-Type: text/plain; charset=UTF-8

An abstract function is a partial interface: I see no value in adding
exceptions to interface implementations, especially if you add that:

 * only works with abstract classes, not interfaces
 * has a too narrow use-case scenario (need more necessity and scenarios
with common patterns)
 * just write a different interface if it doesn't match what you are doing
 * if an abstract class doesn't fit your scenario, just don't extend from it
 * proxying would cause calls to the same methods anyway (on a parent class
or a delegate instance), so parameter and return types should match
exactly, or else you incur in type-juggling-hell (the proxy example is moot)



On 1 Mar 2017 3:21 a.m., "Wes" <netmo.php@gmail.com> wrote:

> Hello internals, I've just created a new RFC, you can read it at:
>
> https://wiki.php.net/rfc/allow-abstract-function-override
>
> Note: I have absolutely no idea how difficult implementing this would be,
> as I have no C/internals knowledge. Thus, patches are very welcome - thank
> you in advance if you intend to work on it!
>
> Regards, Wes
>

--94eb2c19014ea496310549a615e0--