Hi!
As someone mentioned in the thread about short syntax for closures, we
could also drop requirement for function keyword when defining/declaring
methods in classes, interfaces or traits.
I have long noticed how redundant it is. The patch is pretty easy as it
was with commas :)
It is absolutely backwards compatible (you can use function or you can
not use it). Here's the patch: https://gist.github.com/nikita2206/4988075
If people will welcome this proposal, I would need some karma for making
RFC.
Hi,
Hi!
As someone mentioned in the thread about short syntax for closures, we
could also drop requirement forfunctionkeyword when defining/declaring
methods in classes, interfaces or traits.
I proposed this in November '10: http://news.php.net/php.internals/50628
I agreed to the conclusion that the "function" keyword provided a nice
way to grep for functions when handling foreign code and leaving it out
only provides little improvement in less typing.
Please provide new arguments for a new discussion. (That thread was
rather long)
And as a general note I'd like to remind you all about Rasmus' recent
mail: http://news.php.net/php.internals/65894 - In my words: Why not fix
bugs instead of creating new ones?
johannes
On Tue, 19 Feb 2013 17:53:40 -0000, Johannes Schlüter
johannes@schlueters.de wrote:
I agreed to the conclusion that the "function" keyword provided a nice
way to grep for functions when handling foreign code and leaving it out
only provides little improvement in less typing.Please provide new arguments for a new discussion. (That thread was
rather long)And as a general note I'd like to remind you all about Rasmus' recent
mail: http://news.php.net/php.internals/65894 - In my words: Why not fix
bugs instead of creating new ones?johannes
Hmm, I agree about grepping, but how often do you do it? Actually, last
time I grepped php files was half a year ago I think, when I had just ssh
connection and didn't want to mount sshfs. But usually there's IDEs that
can statically analyze your code and let you search against huge codebases
in seconds, I don't want to sound mean, but hey, does anybody greps php
code?
What about reasoning - of course there's no reasons besides less typing.
At the moment, usually when I want to define method, I usually already
know will be in its body so I'm trying to type as fast as I can, and I
often make some mistake in public keyword or function, actually it
happens all the time :) So for me it would be pretty good feature if I
could write one less word.
I agree with Sara about requirement for explicit declaration of visibility
attr.
Hmm, I agree about grepping, but how often do you do it? Actually, last
time I grepped php files was half a year ago I think, when I had just
ssh connection and didn't want to mount sshfs. But usually there's IDEs
that can statically analyze your code and let you search against huge
codebases in seconds, I don't want to sound mean, but hey, does anybody
greps php code?
About 20-30 times every single day.
-Rasmus
Rasmus Lerdorf wrote:
Hmm, I agree about grepping, but how often do you do it? Actually, last
time I grepped php files was half a year ago I think, when I had just
ssh connection and didn't want to mount sshfs. But usually there's IDEs
that can statically analyze your code and let you search against huge
codebases in seconds, I don't want to sound mean, but hey, does anybody
greps php code?
About 20-30 times every single day.
Ditto via the Eclipse equivalent ...
Has anything changed since we last discussed this? And threw it out ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Rasmus Lerdorf wrote:
Hmm, I agree about grepping, but how often do you do it? Actually, last
time I grepped php files was half a year ago I think, when I had just
ssh connection and didn't want to mount sshfs. But usually there's IDEs
that can statically analyze your code and let you search against huge
codebases in seconds, I don't want to sound mean, but hey, does anybody
greps php code?About 20-30 times every single day.
Ditto via the Eclipse equivalent ...
Has anything changed since we last discussed this? And threw it out ...
Yes: the dynamics of the people who vote.
2013/2/19 Nikita Nefedov inefedor@gmail.com:
Hmm, I agree about grepping, but how often do you do it? Actually, last time
I grepped php files was half a year ago I think, when I had just ssh
connection and didn't want to mount sshfs. But usually there's IDEs that can
statically analyze your code and let you search against huge codebases in
seconds, I don't want to sound mean, but hey, does anybody greps php code?
Yes, daily.
Are we really trying to look under ground now for ways to change the
language syntax?
Unless there's a strong case to adding/removing/changing syntax, that
goes well beyond 'because we can' or 'it shortens the code' it
shouldn't even be brought up for discussion.
Zeev
Hi!
As someone mentioned in the thread about short syntax for closures, we could also drop requirement for
functionkeyword when defining/declaring methods in classes, interfaces or traits.I have long noticed how redundant it is. The patch is pretty easy as it was with commas :)
It is absolutely backwards compatible (you can usefunctionor you can not use it). Here's the patch: https://gist.github.com/nikita2206/4988075If people will welcome this proposal, I would need some karma for making RFC.
Are we really trying to look under ground now for ways to change the
language syntax?Unless there's a strong case to adding/removing/changing syntax, that
goes well beyond 'because we can' or 'it shortens the code' it
shouldn't even be brought up for discussion.
I am something of a language guru and to me syntax is extremely
important. Am I of the opinion that removing the function keyword from
the class definition will help? Yes, I am. Do I think it's some
incredible advancement? No, I don't.
The key question for me is: does removing it hurt PHP in any way? And
for me, the answer is a clear and resounding no. I do not grep code
for method definitions: I know exactly where they are and so will my
IDE if I happen to not be using vim. And for those who like to grep
for method definitions they can keep the keyword present.
The key question for me is: does removing it hurt PHP in any way? And
for me, the answer is a clear and resounding no. I do not grep code
for method definitions: I know exactly where they are and so will my
IDE if I happen to not be using vim. And for those who like to grep
for method definitions they can keep the keyword present.
Except when I come along and try to grok your code. I rarely search my
own code.
From the very beginning of PHP we have always favoured readability over
fewer keystrokes.
-Rasmus
The key question for me is: does removing it hurt PHP in any way? And
for me, the answer is a clear and resounding no. I do not grep code
for method definitions: I know exactly where they are and so will my
IDE if I happen to not be using vim. And for those who like to grep
for method definitions they can keep the keyword present.Except when I come along and try to grok your code. I rarely search my
own code.
Protip: use an IDE.
No, I'm serious. I work from the command-line a lot. I grep, awk and
sed a lot of things on a weekly (sometimes daily) basis. However, it
does not replace a good IDE. Ever done a replace from the command
line only to find out you messed up some binary files and/or git/svn
information? Happens all the time when I don't use an IDE; good IDE's
don't make that mistake.
Let's stop pretending that the vast majority of PHP users actually
grep source code looking for function foo. They don't. They don't
even know how to use grep. However, every PHP developer has to write
function and more importantly they have to read function over and
over again.
Does that mean that I think function ABSOLUTELY SHOULD BE made
optional? No. I don't.
Am I tired of everyone complaining about this particular issue and
pointing to the fact that some external tool won't work if you remove
the otherwise unnecessary keyword? Yes, I am. Take a step back and
look at your argument guys: you may have strong personal feelings
about it, but it's a pretty thin argument.
Let's stop pretending that the vast majority of PHP users actually
grep source code looking forfunction foo. They don't. They don't
even know how to use grep.
I don't grep as in grep, but as in "regex search that is part of my
IDE but is not also tokenizing/whateverizing/PHP-aware."
My IDE lets me search for the declaration of a method by
right-clicking class->method(), but it's only able to do that because
it knows how to find the class definition and look there (and it
doesn't use an autoloader). If I want to do a bulk search, it switches
to regex, which doesn't share that intelligence.
But I haven't upgraded to the v8 of this thing, only v7, so who
knows... I find it indispensable and I'm not going to switch to
another one because it isn't "smart enough" to do a PHP-aware bulk
search.
-- S.
While I'm thinking about this (though I should leave it alone): who's
to say that PHP won't some day get inner classes? By deciding the
"default" inner member of a class will be a function, you're choosing
the one that has a global/procedural equivalent where the short syntax
won't work, instead of leaving the concept unused for the possible
future when:
class myClass {
mySomething { // is equivalent to class mySomething {
(Yes, you could say mySomething(...) { } is a public function and
mySomething { } is an innner class, but you get the idea.)
-- S.
On Wed, 20 Feb 2013 08:02:36 -0000, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
While I'm thinking about this (though I should leave it alone): who's
to say that PHP won't some day get inner classes? By deciding the
"default" inner member of a class will be a function, you're choosing
the one that has a global/procedural equivalent where the short syntax
won't work, instead of leaving the concept unused for the possible
future when:class myClass {
mySomething { // is equivalent to class mySomething {
(Yes, you could say mySomething(...) { } is a public function and
mySomething { } is an innner class, but you get the idea.)-- S.
Classes always should be declared with class keyword, because there could
be ambiguity whether it's class, interface or trait.
Also, I will say it again: as Sara noted, we really shouldn't let users
define methods without any modifiers, like this: class Foo { asd() { echo
"this is parse error"; } }
Classes always should be declared with class keyword, because there could
be ambiguity whether it's class, interface or trait.
If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether "something{}" just inside a a class is an
inner class.
That's the justification for removing "function" just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form "sometype somevisibility something(){}" is a
function?
Well, if in PHP.later, the only thing that takes the form "sometype
something{}" is an inner class, then leaving off the "sometype" there
is also unambiguous (but also similarly gratuitous).
And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
"interface something{}" is an inner intf.
(I'm attempting a RAA argument but maybe failing....)
-- Sandy | FigureOne Support Team
Sandy,
On Wed, Feb 20, 2013 at 11:59 AM, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
Classes always should be declared with class keyword, because there could
be ambiguity whether it's class, interface or trait.If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether "something{}" just inside a a class is an
inner class.That's the justification for removing "function" just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form "sometype somevisibility something(){}" is a
function?Well, if in PHP.later, the only thing that takes the form "sometype
something{}" is an inner class, then leaving off the "sometype" there
is also unambiguous (but also similarly gratuitous).And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
"interface something{}" is an inner intf.(I'm attempting a RAA argument but maybe failing....)
-- Sandy | FigureOne Support Team
I think you've abstracted this one way too much.
For me right now all I see is a useless keyword in a class. We don't
have 'visbilitytype var/property $varName' right now but you are
comfortable with them knowing that they are just properties of the
class.
If I were to be on this road I could in fact argue that currently we have
a lack of consistency between class methods and properties. You can
have a look on this image if you want an example:
http://i.imgur.com/Q0ZOZns.png
For the part where public is optional, I think that most frameworks
and practices they promote and users actually do type the keyword
and have it there for the sake of consistency. It might not be the case
for now, but I think that it would rather be useful to enforce the visibility
types rather that the 'function' keyword.
As for classes/interfaces/traits and so on, if they are ever added in PHP
to be declared inside classes and so on then I see no issues with this.
A class/interface or a trait keyword would still be needed to make the
difference between a them imho.
Grepping for sources is like a daily operation and by using IDEs like
Netbeans/Eclipse/PHPStorm one has the ability to just search for a
symbol directly, regardless if you can click of function name or not.
No voting karma here as well but I do tons of code reviews and this is
just my opinion, you know, from the userland.
Regards.
Florin Patan
https://github.com/dlsniper
As for classes/interfaces/traits and so on, if they are ever added in PHP
to be declared inside classes and so on then I see no issues with this.
A class/interface or a trait keyword would still be needed to make the
difference between a them imho.
No, if you only allow inner classes at any point, you don't have
ambiguity. So by your standard, that version of PHP should drop the
keyword because there's only one unambiguous "something{}"
construction in that context.
I'm not saying you should drop the keyword, I'm just explaining what
I think is the slippery slope of this kind of non-improvement.
Grepping for sources is like a daily operation and by using IDEs like
Netbeans/Eclipse/PHPStorm one has the ability to just search for a
symbol directly, regardless if you can click of function name or not.
I don't think you followed the matter of complex search/replace and
the new regex you'd have to "just" use all the time. I use a
sophisticated IDE as I mentioned, but its s/r function is separate
from its "find declaration" function. Not to mention searching for
duplicate declarations or in files you don't have in your workspace.
This is a real problem and I'm very happy we don't have it now.
No voting karma here as well but I do tons of code reviews and this is
just my opinion, you know, from the userland.
I am debating from userland as well. But I'm all done w/this one.
-- S.
On Wed, 20 Feb 2013 09:59:51 -0000, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
Classes always should be declared with class keyword, because there
could
be ambiguity whether it's class, interface or trait.If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether "something{}" just inside a a class is an
inner class.That's the justification for removing "function" just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form "sometype somevisibility something(){}" is a
function?Well, if in PHP.later, the only thing that takes the form "sometype
something{}" is an inner class, then leaving off the "sometype" there
is also unambiguous (but also similarly gratuitous).And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
"interface something{}" is an inner intf.(I'm attempting a RAA argument but maybe failing....)
-- Sandy | FigureOne Support Team
So no you are not saying "PHP is not Java or C#". I don't want to touch
any religious views but it's really funny to read :)
So no you are not saying "PHP is not Java or C#". I don't want to touch
any religious views but it's really funny to read :)
Not sure I get your remark... of those languages, I've said, in
essence [1] "Don't force PHP to look less like Java, ECMAScript, C#,
or C++ without a good reason and a new feature" and [2] "Don't
preclude other languages' advanced features from being added to PHP
later -- even much later -- with their most obvious syntax by clipping
syntax in PHP.now so that later additions are more difficult."
And PHP is looking more like ES in some ways (array literals). I like
that. I don't insist on it, but it's a leg up. CF did that too a while
back, and that brought me back to it for a project.
As I said, if inner classes are ever added to PHP, it stands to reason
they would follow the syntax of other C-style languages. And you might
then apply your (I believe flawed) argument that "any token that could
be considered superfluous in a given parser context and PHP version
should become optional" with the default meaning being permanently
fixed as of that PHP version.
It doesn't stand up to scrutiny because you just end up with more
magic to remember and no real advantages, especially over time.
But really, really truly, I am not going to comment again on this
thread but just wish you luck in swaying the people that count!
Cheers,
-- S.
Let's stop pretending that the vast majority of PHP users actually
grep source code looking forfunction foo.
That was never said, but there's a big number of people who has to deal
with code produced by others and doing tasks where it is not always
appropriate to startup and IDE and create a project and index it and
"grep" is not always a simple grep but some more complex operation
involving a search.
And as you are happy with your idea you can certainly create shortcuts
so you can type "puf" or such instead of "public function" and maybe
even to hide the "function" word.
They don't. They don't
even know how to use grep. However, every PHP developer has to write
functionand more importantly they have to readfunctionover and
over again.
The ones who don't know about 'grep' are happy about the extra clue.
Am I tired of everyone complaining about this particular issue and
pointing to the fact that some external tool won't work if you remove
the otherwise unnecessary keyword? Yes, I am. Take a step back and
look at your argument guys: you may have strong personal feelings
about it, but it's a pretty thin argument.
The argument for removing (or rather: the argument for adding yet
another alternate syntax) is even weaker. Code is more often read than
written.
Now let's focus on work.
johannes
(who will now ignore this thread - we're turning in circles)
Protip: use an IDE.
The IDE that i'm using may search for something like function \w to find
all the functions of my code. So I may have to wait for a new update of the
IDE to be able to use the index, and I also may have to pay to get the
update of my IDE. So why would I want all this if I can just keep the
function keyword.
Pierrick
I am something of a language guru and to me syntax is extremely
important. Am I of the opinion that removing the function keyword from
the class definition will help? Yes, I am.
I'm missing the help. It saves 9 characters and creates a disjunction
between global function syntax and function-as-method syntax? Sorry, I
can't see this as anything better than neutral.
And for those who like to grep for method definitions they can keep
the keyword present.
... in their own code, not in all the code they are forced to maintain
(whether that be newbie sloppy code or super-cool library code).
-- S.
The key question for me is: does removing it hurt PHP in any way? And
for me,
the answer is a clear and resounding no.
This is completely the wrong question to ask (IMHO). I think the answer
is wrong too, but that's a different story.
The correct question is:
"Does it bring substantial value to be considered for inclusion in one of
the world's most popular programming languages?" For me, the answer is a
clear and resounding no.
From my POV that's where the story ends. The whole discussion about greps
and IDEs misses the point - we shouldn't even be discussing a 'feature'
that brings no value to the table.
The only reason I wrote my reply is that we seem to be having an influx of
those RFCs that fail this very basic requirement.
Zeev
Are we really trying to look under ground now for ways to change the
language syntax?
Agree 100%. Not to mention, I plan on eventually convincing enough people to replace that keyword with a type hint ;)
Unless there's a strong case to adding/removing/changing syntax, that
goes well beyond 'because we can' or 'it shortens the code' it
shouldn't even be brought up for discussion.Zeev
Hi!
As someone mentioned in the thread about short syntax for closures, we could also drop requirement for
functionkeyword when defining/declaring methods in classes, interfaces or traits.I have long noticed how redundant it is. The patch is pretty easy as it was with commas :)
It is absolutely backwards compatible (you can usefunctionor you can not use it). Here's the patch: https://gist.github.com/nikita2206/4988075If people will welcome this proposal, I would need some karma for making RFC.