Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66024
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
References: <op.wsrvzpbsc9evq2@nikita2206-debian> <5123BE51.7060500@oracle.com> <op.wsrzvdhec9evq2@nikita2206-debian> <5123CE1E.5020500@lerdorf.com> <op.wsrz25qdc9evq2@nikita2206-debian> <CAEU6NAcopd9d-JQvrvwSh1rd4=HEkW_06M6bcfobcA4_Kav2rg@mail.gmail.com> <1586876476.20130219164246@cypressintegrated.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <1586876476.20130219164246@cypressintegrated.com>
Message-ID: <407C7FA9-ABA7-4C01-A04C-AEA056F372FB@gmail.com>
Date: Wed, 20 Feb 2013 12:19:27 +0400
To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>,
 "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
From: inefedor@gmail.com (Nikita Nefedov)

On 20.02.2013, at 1:42, Sanford Whiteman <swhitemanlistens-software@cypressi=
ntegrated.com> wrote:

> Seems this would complicate the transplanting of (global) functions
> into (default public) class methods and vice versa. This is a common
> refactoring task -- at least IME -- and before I adjust visibility I
> would expect the function to Just Work.
>=20
> So this works in a class to define the function:
>=20
> function my_function() { }
>=20
> And I expect to be able to pull that out into the global scope as-is.
>=20
> But if people start using this super-shorthand in the class:
>=20
> my_function() { }
>=20
> Then when I pull it out into my function library, I'll get errors.
>=20
> The reverse is also true: I expect to get a fatal from leaving off a
> semicolon between function_call() and {} but at the top level of a
> class it gets smoothly compiled as a function definition.
>=20
> Look, I know there are similar cases throughout PHP (and other
> languages) already, but why add more for no (IMO) payoff? Perhaps not
> the most compelling case against this new sugar, but it would suffice
> to stop me from ever using it.

Hi Sandy, it won't complicate you anything.
Global functions remain its requirement for keyword, just methods lose it. A=
nd it doesn't mean that you can't write
class Foo {
function bar() {}
}

As I said, there are no bc breaks at all. My initial patch doesn't forces yo=
u to write any keyword, so you are actually can declare a method just with f=
oo(){}, but it is absolutely doable, i'm just from my cell phone now.


What about readability - removal of this keyword will make a better readabil=
ity of methods. Instead of
abstract class Foo {
public function make()
{
    // some code
}

public abstract function do();
}

You will need to read just
class Foo {
public make()
{
    // some code
}

public abstract do();
}

It's not function a keyword who lets you recognize function definition/decla=
ration, but it's usually a pair of brackets. This function keyword is just n=
oise for now, it doesn't serve any purpose aside from typing grep 'function f=
uncname' instead of grep '(private|protected|public|abstract|static)funcname=
' , but, you know, if you love shell so much (or are forced to use it) you a=
re probably familiar with creating 'shortcuts' for it, scripts or aliases.


Now what I think about all this "give the arguments" - the thing is - functi=
on keyword is just redundant. It's like appendix, we just don't need it, the=
re's no point in it (yeah, except grepping), and we can drop it without any b=
c breaks, so why don't just do it?=