PHP 5.6.1 is available

Am 03.10.2014 um 19:38 schrieb Levi Morrison levim@php.net:

On Fri, Oct 3, 2014 at 10:21 AM, Thomas Gossmann mail@gossimaniac.net
wrote:

Hey there,

I'm just a php developer, thus not even having a php.net account.

I was wondering if it is possible to deprecate/remove the function keyword
from class methods in php7 or at least make it optional when one of the
visibility keywords is present?

I feel like writing a completely unnecessary keyword each time I write a
new method for a class.

I guess this was a discussion earlier, though I wasn't able to find
anything about it. Would love to hear, what pdt-internals (re-)think about
that topic.

Thanks,
gossi

Removing the function keyword makes it more difficult for people to find
method definitions. This has historically been a significant factor in why
this hasn't been done.

Also, what does this change actually bring to the table? There is no actual
benefit to the language or tooling; in fact it probably makes the tooling
more difficult. All this means is that the user types the function keyword
less and saves a very, very small amount of time.

In summary, historically we have felt that the benefits do not outweigh the
drawbacks.

I usually just observe on this list, but this is a topic I have come across myself.

PHP has followed the C++ syntax, and logical scoping like namespace,s since a long time - if not, eversince. C++ does not use a function keyword by itself, and even lesser visibility keywords as PHP does.

I find it rather ugly seeing „public function foo()“ everywhere, when everybody knows that parantheses mean function. So, I see readability as a plus.

<?php class Foo {
public bar($a, $b) { return $a+$b; }
} ?>

It actually is not a drawback, but rather an enhancement that would increase PHP’s readability, in my opinion. It could be introduced as „syntactic shuggar“, where people can, but dont have to, use the function keyword. For the lexer, this just seems to be one more if().

I don’t see a lot of evolution in PHP lately, so something small as this might be pretty nice! :)

Hi!

Easy to implement, too. What are the list’s thoughts? I don’t think it really hampers readability much.

It's pretty faint praise - "doesn't hamper much". I think language
feature should do better than not hurting too much. We don't need to
change things and fragment the language just because we can do it
without hurting too much. Instead, we should think about what it would
improve - and frankly I don't see too much improvement coming out of it.
We've discussed this a number of times, it's not broken, it doesn't need
fixing.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

Easy to implement, too. What are the list’s thoughts? I don’t think it really hampers readability much.

I disagree. This is a case where verbosity is a good thing. Removing
the word 'function' is akin (pardon the analogy) to arguing the $x is
just as good of a variable name as $database.

The latter is descriptive and explains exactly what is going on. While
the shortened version, only saves a few keystrokes, which an IDE solves
for you anyway. And makes it much more clear (when grepping, for
tooling, when scanning) exactly what/where/how the functions are declared.

Eli

--
| Eli White | http://eliw.com/ | Twitter: EliW |

I was wondering if it is possible to deprecate/remove the function
keyword from class methods in php7 or at least make it optional when one of
the visibility keywords is present?

I feel like writing a completely unnecessary keyword each time I write
a new method for a class.

I guess this was a discussion earlier, though I wasn't able to find
anything about it. Would love to hear, what pdt-internals (re-)think about
that topic.

Me and Pierre have discussed this before, Pierre was in favour of it last
time we talked about it. I’d certainly be in favour of allowing function
to be omitted when there’s a visibility specifier, like so:

public foo() {}
public static foo() {}

Easy to implement, too. What are the list’s thoughts? I don’t think it
really hampers readability much.

Same here. Also while not being against that, I am not a fan or removing
things that make hard to have code for 5.x and 7.x. That will make
migrations harder for little to no gain.

Did we not have a rfc about that already?

Thank you for your input and comments, which let me think through some
of them and my initial thoughts. Here is what I come up with.

Perfection is reached when there is nothing left to remove. So in a
perfect world, a class could look like this:

class Foo {
bar() {}
baz() {}
}

When the visibility specifier is omitted, it defaults back to public
(However, personally I don't think this is good practice). Semantically
it is not even a function, it is a method. Literally the function
keyword is a tautology, because actually the parens signal what that
property is, which raises redundancy in writing the function keyword.

The converse argument basically marks its gain, writing redundant
syntactical parts is removed. Yes, IDEs can help with that (though I'm
faster typing function instead of triggering auto-complete, because it
shifts my hand off writing) but given the fact that I must do it,
although unnecessary, questions its existence - instead of let the dev
continue typing.

My simple example from above is a result which also happened in the
javascript world, where they also abandoned the function keyword for
classes, because parens offer the semantics. To me it is more readable
and as a person who cares for esthetics I think this is also more
beautiful. Hence, for php-beginners, this example of a simple class is a
good start, which can also be used educating them in OOP by adding the
more advanced parts - instead of letting them write function when this
actually is a method (In my eyes, education failed here).

I really see a point in support tooling, which is fundamental to support
programming languages. What wonders me, is that arguments targeting
tooling (secondary consumers) have more value than those arguments
targetting php developers (primary consumers) (or at least this is how I
recognize them - please hint me if I'm wrong). As long as it wouldn't
make detecting methods impossible, it just raises the challenge for
tooling authors, but that's it. Basically, you write your detection
algorithm for methods once and then reuse it vs. php developers writing
methods over and over again. I think in a statistical investigation, the
latter outnumber the first.
For those, that want to grep their code for a function keyword, still
can continue to write it (only for sake of beeing able to grep it).

To summarize and conclude the gains of making the function keyword for
methods optional, which keeps BC intact:

• Remove writing a redundant unnecessity (faster writing)
• Remove the failure of educating beginners wrong
• Easier classes for beginners

At the cost of a slight improved challenge for tooling authors and their
detecting algorithms for methods, which they probably write once - I
think this is a fair trade.

Thomas Gossmann

Am 03.10.14 um 22:57 schrieb Andrea Faulds:

I was wondering if it is possible to deprecate/remove the function keyword from class methods in php7 or at least make it optional when one of the visibility keywords is present?

I feel like writing a completely unnecessary keyword each time I write a new method for a class.

I guess this was a discussion earlier, though I wasn't able to find anything about it. Would love to hear, what pdt-internals (re-)think about that topic.

Me and Pierre have discussed this before, Pierre was in favour of it last time we talked about it. I’d certainly be in favour of allowing function to be omitted when there’s a visibility specifier, like so:

public foo() {}
public static foo() {}

Easy to implement, too. What are the list’s thoughts? I don’t think it really hampers readability much.

Andrea Faulds
http://ajf.me/

Thanks Johannes, I slipped over it but would have never found the
discussion to it.

I run over it and the summary is: Many people like it and those that
don't have brought arguments, that are present here again. The
discussion is almost 4 years old by now, and people are complaining over
things getting implemented in php back in time, which are now
implemented and turned out to be ok - I expect the same to happen with
this idea.
Main contra argument is, people are not able to grep for 'function *'
anymore, which I guess is a minority of people and they can write
themselves a shell-script which makes it possible to search for
functions again, so not a big deal. However, the more important
statement behind this is, who is the more important crowd of people that
are targeted with changes like these? Primary or secondary consumers?
... but see my other mail, which conatains answers.

Though, I have one question left regarding the old rfc? Why it has been
gone inactive and basically slept since then?

Thanks
Thomas Gossmann

Am 04.10.14 um 19:44 schrieb Johannes Schlüter:

I guess this was a discussion earlier, though I wasn't able to find
anything about it. Would love to hear, what pdt-internals (re-)think
about that topic.

Go to wiki.php.net/rfc look at the titles containing "function" and you
will see "Make T_FUNCTION in method declarations optional" which was
added by me. https://wiki.php.net/rfc/optional-t-function

Since proposing I was convinced this wasn't good. Please bring new
arguments. Discussion was in this thread
http://news.php.net/php.internals/50628 (another viewer might be better
to find the ~64 followups)

johannes