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:
On 3 Oct 2014, at 17:21, Thomas Gossmann <m...@gossimaniac.net> wrote:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
