Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59131
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 87.106.212.190 cause and error)
Message-ID: <4F6C1DCC.1090301@hoa-project.net>
Date: Fri, 23 Mar 2012 07:53:00 +0100
Reply-To: ivan.enderlin@hoa-project.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGovj_No0kd2fzVbG+hMgnMV=cQEsuf1yory-FDWWzHSQpCL=g@mail.gmail.com>
In-Reply-To: <CAGovj_No0kd2fzVbG+hMgnMV=cQEsuf1yory-FDWWzHSQpCL=g@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Override keyword
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

Hi Michael,

I think your proposition is related to annotations. It is a =93service=94=
,=20
an _information_, so it clearly belongs to annotations, documentation or =

IDE domain, but it does not belong to the language. Are you agree with th=
is?

Best regards.

On 22/03/12 21:27, Michael Morris wrote:
> Without cluttering the RFC list up further (I fear I've done too much
> of that with the last two bombed suggestions), I'd just like to come
> out and ask if the addition of an override keyword on classes had ever
> been considered?  I'd see it as more than a self documenting thing for
> BC reasons than anything else since, for BC we have to allow functions
> to override even if they don't have the keyword.  But if a method is
> declared as an override, and none of the parent classes or imported
> traits have that method, then stating override would be a fatal error.
>
> Or, given...
>
> class A {
>    public function foo() {}
> }
>
> class B extends A {
>    public function foo ( $val ) {}
> }
>
> This is ok to avoid a backwards compat break, though if a move to
> require the override keyword was desired an E_STRICT might be raised.
>
> class C extends A {
>    public override function foo ( $val ) {}
> }
>
> The only real advantage I will admit is self documentation by the
> code.  We know C's foo is overriding something without opening A's
> class file.
>
> class D extends A {
>    public override function bar ( $val ) {}
> }
>
> And this would raise E_FATAL. No existing code would be affected, and
> a programmer using this keyword would, I assume, want to be alerted
> that the override they are expecting doesn't exist.  After all, if
> their override calls the parent method, they'd get an error anyway.
>
>
> I can write an RFC for this, but the last two I wrote got shouted down
> in such swift succession I think it would be better to get this vetted
> before writing the RFC.
>

--=20
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/