Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66038
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
Date: Wed, 20 Feb 2013 04:42:26 -0500
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Message-ID: <92031573.20130220044226@cypressintegrated.com>
To: Nikita Nefedov <internals@lists.php.net>
In-Reply-To: <407C7FA9-ABA7-4C01-A04C-AEA056F372FB@gmail.com>
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> <407C7FA9-ABA7-4C01-A04C-AEA056F372FB@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman)

> Global functions remain its requirement for keyword, just methods
> lose 

I understand that. You didn't read my post carefully because I was
noting this exact inconsistency.

> it. And it doesn't mean that you can't write
> class Foo {
> function bar() {}
> }

No, it means you _have to_ write it that way if you want the same
function definition to work in and out of a class. Like I said, I
expect the simplest function def to Just Work (as it does now) in
either scope.

This is not a technical BC break but a conceptual break that
disregards existing realities of refactoring (as well as realities of
who writes the code we end up maintaining). 

> What about readability - removal of this keyword will make a better
> readability 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();
> }

That's no more readable to me. And even if I pretended to find it so,
I want to to read other contemporary languages with relative ease as
well, rather than being coddled by sugar that doesn't exist in other
C-style languages. PHP is not Java or C#, yes; yet the more
"streamlined" we get while those languages are adding actual features,
the worse off we'll be when we have to get the gist of something in a
verbose foreign language. And I don't want to drop "function" on the
server and then forget it in JavaScript. That's a net loss for me and
the millions of other users jacking both trades.

> It's not function a keyword who lets you recognize function
> definition/declaration, but it's usually a pair of brackets. 

The function(){} construction is critical to recognizing a function
definition. Simply looking for curly braces is not sufficient, since
obviously a {} block does not mean you're in a function. {} is perhaps
more predictive at the second level of a class file, but in a codebase
in general it would be reckless to treat {}, or even (){}, as denoting
a function definition, since the former squarely does not and the
latter is more likely to mean an forgotten semicolon in real-world
code.

> This function keyword is just noise for now, it doesn't serve any
> purpose aside from typing grep 'function funcname' 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 are
> probably familiar with creating 'shortcuts' for it, scripts or
> aliases.

I could scarcely disagree more with your minimizing view of how people
seek and scan code.

I think I'd better stop discussing it as well -- I don't have voting
karma so good luck either way....

-- S.