Support for keywords where possible

11 years ago by Lazare Inepologlou — view source

unread

2013/9/11 Bob Weinand bobwei9@hotmail.com

Hi!

I tried to widen the naming possibilities by allowing to use keywords as
identifiers (for function names, class names, label (goto) names, ...)
where possible. It doesn't break any BC.

Furthermore when BC needs to be broken in future for new keywords, it will
have a smaller impact as most usages of the new keyword then still work.

It also prevents unnecessary workarounds like in
https://wiki.php.net/rfc/named_params#syntax. There, to address a
function with a parameter called $array, we could simply write func(array
=> $value); instead of the until now necessary func("array" => value);

You can find the patch here:
https://github.com/php/php-src/pull/438

Any thoughts about this?

I like it! I always hated the fact that "list" is a reserved word.

Lazare INEPOLOGLOU
Ingénieur Logiciel

11 years ago by Benjamin Eberlei — view source

unread

Hey Bob,

I like it very much, i flew over the patch to see what would be possible,
and that includes many of the points that annoy me most of the time :-)

greetings
Benjamin

Hi!

I tried to widen the naming possibilities by allowing to use keywords as
identifiers (for function names, class names, label (goto) names, ...)
where possible. It doesn't break any BC.

Furthermore when BC needs to be broken in future for new keywords, it will
have a smaller impact as most usages of the new keyword then still work.

It also prevents unnecessary workarounds like in
https://wiki.php.net/rfc/named_params#syntax. There, to address a
function with a parameter called $array, we could simply write func(array
=> $value); instead of the until now necessary func("array" => value);

You can find the patch here:
https://github.com/php/php-src/pull/438

Any thoughts about this?

Bob Weinand

11 years ago by Ryan McCue — view source

unread

Bob Weinand wrote:

I tried to widen the naming possibilities by allowing to use keywords as identifiers (for function names, class names, label (goto) names, ...) where possible. It doesn't break any BC.

Is the token still T_LIST/T_DEFAULT given that example above, or would
those be T_STRINGs now? I can think of a bunch of userland stuff
(basically every documentation generator) that will break if the
class/function name is not a T_STRING.

That said, +1 for the feature, great idea.

--
Ryan McCue
<http://ryanmccue.info/

11 years ago by Michael Wallner — view source

unread

Hi!

I tried to widen the naming possibilities by allowing to use keywords as identifiers (for function names, class names, label (goto) names, ...) where possible. It doesn't break any BC.

Furthermore when BC needs to be broken in future for new keywords, it will have a smaller impact as most usages of the new keyword then still work.

I like the idea, but it looks like the patch defers many string
comparisons from the parser to strcmps. Do you have performance
comparisons of running e.g. a framework, which uses those keywords a
lot?

--
Regards,
Mike

11 years ago by Bob Weinand — view source

unread

Am 12.9.2013 um 09:10 schrieb Michael Wallner mike@php.net:

Hi!

I tried to widen the naming possibilities by allowing to use keywords as identifiers (for function names, class names, label (goto) names, ...) where possible. It doesn't break any BC.

Furthermore when BC needs to be broken in future for new keywords, it will have a smaller impact as most usages of the new keyword then still work.

I like the idea, but it looks like the patch defers many string
comparisons from the parser to strcmps. Do you have performance
comparisons of running e.g. a framework, which uses those keywords a
lot?

--
Regards,
Mike

A little benchmark here: https://gist.github.com/bwoebi/6536824

Here I picked always the best from 10 times running.

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 8.6687519550323 seconds

Without patch:
root# ./sapi/cli/php ../bwo-php-src/microbench.php
Took for 10000 iterations: 8.5741410255432 seconds

But this is the very worst case. (e.g. there are JUST cases where strncasecmp needs to be used)

When picking random files the results are pretty similar:

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.564201116562 seconds

Without patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.562065023422 seconds

It's here only a difference of about 2 milliseconds or 0,01% what is in the margin of error I think.

Bob Weinand

11 years ago by Michael Wallner — view source

unread

A little benchmark here: https://gist.github.com/bwoebi/6536824

Here I picked always the best from 10 times running.

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 8.6687519550323 seconds

Without patch:
root# ./sapi/cli/php ../bwo-php-src/microbench.php
Took for 10000 iterations: 8.5741410255432 seconds

But this is the very worst case. (e.g. there are JUST cases where strncasecmp needs to be used)

Is there a number missing after "JUST"?

When picking random files the results are pretty similar:

What random files?

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.564201116562 seconds

Without patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.562065023422 seconds

It's here only a difference of about 2 milliseconds or 0,01% what is in the margin of error I think.

I'd love to have the freedom your patch provides, but I'm not convinced yet :)
How does it affect running one of the major frameworks out there?

--
Regards,
Mike

11 years ago by Benjamin Eberlei — view source

unread

Bob,

you should maybe run the testsuite for example of symfony2, it has 11k
tests and runs not too long. This should be a good benchmark. Phpunit
reports the execution times.

greetings
Benjamin

A little benchmark here: https://gist.github.com/bwoebi/6536824

Here I picked always the best from 10 times running.

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 8.6687519550323 seconds

Without patch:
root# ./sapi/cli/php ../bwo-php-src/microbench.php
Took for 10000 iterations: 8.5741410255432 seconds

But this is the very worst case. (e.g. there are JUST cases where
strncasecmp needs to be used)

Is there a number missing after "JUST"?

When picking random files the results are pretty similar:

What random files?

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.564201116562 seconds

Without patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.562065023422 seconds

It's here only a difference of about 2 milliseconds or 0,01% what is in
the margin of error I think.

I'd love to have the freedom your patch provides, but I'm not convinced
yet :)
How does it affect running one of the major frameworks out there?

--
Regards,
Mike

11 years ago by Bob Weinand — view source

unread

Am 12.9.2013 um 15:06 schrieb Michael Wallner mike@php.net:

A little benchmark here: https://gist.github.com/bwoebi/6536824

Here I picked always the best from 10 times running.

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 8.6687519550323 seconds

Without patch:
root# ./sapi/cli/php ../bwo-php-src/microbench.php
Took for 10000 iterations: 8.5741410255432 seconds

But this is the very worst case. (e.g. there are JUST cases where strncasecmp needs to be used)

Is there a number missing after "JUST"?

no… I mean, in the benchmark are included all the cases where strncasecmp needs to be used.

When picking random files the results are pretty similar:

What random files?

Some PHP files that were on my server

With patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.564201116562 seconds

Without patch:
root# ./sapi/cli/php microbench.php
Took for 10000 iterations: 15.562065023422 seconds

It's here only a difference of about 2 milliseconds or 0,01% what is in the margin of error I think.

I'd love to have the freedom your patch provides, but I'm not convinced yet :)
How does it affect running one of the major frameworks out there?

--
Regards,
Mike

As Benjamin suggested, here the best running times of "time phpunit" in the symfony test suite:

With patch:
real 0m30.885s
user 0m14.713s
sys 0m2.123s

Without patch:
real 0m31.380s
user 0m14.865s
sys 0m2.170s

Seems that it is very similar (I have here variances of ±2 seconds…) So I think my patch doesn't have a huge impact.

Bob Weinand

11 years ago by Michael Wallner — view source

unread

As Benjamin suggested, here the best running times of "time phpunit" in the symfony test suite:

With patch:
real 0m30.885s
user 0m14.713s
sys 0m2.123s

Without patch:
real 0m31.380s
user 0m14.865s
sys 0m2.170s

Seems that it is very similar (I have here variances of ±2 seconds…) So I think my patch doesn't have a huge impact.

Looks good to me.

--
Regards,
Mike

11 years ago by Pierre Joye — view source

unread

hi,

As Benjamin suggested, here the best running times of "time phpunit" in the symfony test suite:

With patch:
real 0m30.885s
user 0m14.713s
sys 0m2.123s

Without patch:
real 0m31.380s
user 0m14.865s
sys 0m2.170s

Seems that it is very similar (I have here variances of ±2 seconds…) So I think my patch doesn't have a huge impact.

We will try to run it through our performance tests suite here,
against more applications. I do not think we will see different
results but at least the coverage will be large enough to make an
informed choice :)

About the idea itself, I like it and all for it, as long as it does
not introduce any BC breaks. I doubt there is any and testing it
intensively against existing apps will clear this point.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by johannes@schlueters.de — view source

unread

Hi!

I tried to widen the naming possibilities by allowing to use keywords
as identifiers (for function names, class names, label (goto)
names, ...) where possible. It doesn't break any BC.

I often stumbled over the annoyance of this limitation and I know many
users want it, I'm not convinced about adding it, though.

One reason is the "where (easily) possible" part. Right now we have a
simple rule "keywords can't be reused". This is being changed to "this
and that keyword can be used her and there." I don't believe this is
good.

Secondly I'm among the people who read tons of "bad" code and I'm sure
people will abuse this and we will find code like this:

&lt;?php
namespace network;
function if($which) {
    // ... some logic ...
        return "eth0";
 }
 // ... somewhere else in the namespace ...
 if($condition);
 ?>

This can hide subtile typos or coding errors. Also look at currently
valid PHP code like this:

&lt;?php
function while() {}
$condition = true;
while ($condition)
?>

and while reading this mind that an ; in front of an ?> is optional, so
will this call a function and exit or be stuck in an infinite loop?

I'm sure one could construct other such cases.

I'm more open about allowing such identifiers as method names only, as
those are prefixed in some way ($object-> or someClass:: ) but even
there I tend to consider the consistency between function and method
names more important than this flexibility.

I couldn't test those examples as your branch for some reason didn't
work, even though I made sure I regenerated the parser, but I didn't
look deeper, maybe my fault.

    001+ Parse error: syntax error, unexpected 'catch' (T_CATCH),
    expecting identifier (T_STRING) or \\ (T_NS_SEPARATOR) or '{'
    in /.../Zend/tests/identifier_or_keyword_001.php on line 3
    001- Ok
    002- Fatal error: %s in %s on line %d

johannes

11 years ago by Nikita Popov — view source

unread

On Thu, Sep 12, 2013 at 10:44 PM, Johannes Schlüter
johannes@schlueters.dewrote:

I often stumbled over the annoyance of this limitation and I know many
users want it, I'm not convinced about adding it, though.

One reason is the "where (easily) possible" part. Right now we have a
simple rule "keywords can't be reused". This is being changed to "this
and that keyword can be used her and there." I don't believe this is
good.

Secondly I'm among the people who read tons of "bad" code and I'm sure
people will abuse this and we will find code like this:
&lt;?php
namespace network;
function if($which) {
    // ... some logic ...
        return "eth0";
 }
 // ... somewhere else in the namespace ...
 if($condition);
 ?>
This can hide subtile typos or coding errors. Also look at currently
valid PHP code like this:
&lt;?php
function while() {}
$condition = true;
while ($condition)
?>
and while reading this mind that an ; in front of an ?> is optional, so
will this call a function and exit or be stuck in an infinite loop?

I'm sure one could construct other such cases.

I'm more open about allowing such identifiers as method names only, as
those are prefixed in some way ($object-> or someClass:: ) but even
there I tend to consider the consistency between function and method
names more important than this flexibility.

I tend to agree with Johannes. Supporting different sets of keywords in
different locations is pretty confusing. Imho we should add this kind of
support only in places where a) we can support all keywords and b) it is
unlikely that supporting keywords there will cause issues in the future.

One such case are method names. Methods with keyword names are currently
callable using $foo->array(), because the identifier after
T_OBJECT_OPERATOR is always a T_STRING. But while you can call them, it is
currently not possible to define them as real methods. Instead you need to
forward them via __call magic, which is rather ugly. Internal classes on
the other hand can and do define methods with reserved-keyword names. E.g.
there is a Generator::throw() method.

Nikita

11 years ago by Pierre Joye — view source

unread

I tend to agree with Johannes.

I tend to agree too but I never really liked this keywords restriction.

Supporting different sets of keywords in
different locations is pretty confusing. Imho we should add this kind of
support only in places where a) we can support all keywords and b) it is
unlikely that supporting keywords there will cause issues in the future.

b) can't be proofed, also the keyword problem being future ready is
also a shiny myth. It is a moving target.

One such case are method names. Methods with keyword names are currently
callable using $foo->array(), because the identifier after
T_OBJECT_OPERATOR is always a T_STRING. But while you can call them, it is
currently not possible to define them as real methods. Instead you need to
forward them via __call magic, which is rather ugly. Internal classes on
the other hand can and do define methods with reserved-keyword names. E.g.
there is a Generator::throw() method.

This exact case is actually a very good reason to accept this proposal.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Bob Weinand — view source

unread

Am 12.9.2013 um 22:59 schrieb Pierre Joye pierre.php@gmail.com:

Supporting different sets of keywords in
different locations is pretty confusing. Imho we should add this kind of
support only in places where a) we can support all keywords and b) it is
unlikely that supporting keywords there will cause issues in the future.

a) has the problem while we can now define a class List {} (<= allows all keywords),
we cannot access List::const; (<= not all keywords are allowed here).
(To still access it, it would have to be an uglier namespace\List::const;)

See also https://github.com/php/php-src/pull/438 for which combinations of keywords
are possible.

b) can't be proofed, also the keyword problem being future ready is
also a shiny myth. It is a moving target.

They actually aren't future ready for all cases; in my initial mail I wrote:
"Furthermore when BC needs to be broken in future for new keywords, it will have a
smaller impact as most usages of the new keyword then still work."

It will only make the impact smaller; I didn't say that it will make disappear any impact.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

Bob Weinand

11 years ago by Bob Weinand — view source

unread

Am 12.9.2013 um 22:44 schrieb Johannes Schlüter johannes@schlueters.de:

Hi!

I tried to widen the naming possibilities by allowing to use keywords
as identifiers (for function names, class names, label (goto)
names, ...) where possible. It doesn't break any BC.

I often stumbled over the annoyance of this limitation and I know many
users want it, I'm not convinced about adding it, though.

One reason is the "where (easily) possible" part. Right now we have a
simple rule "keywords can't be reused". This is being changed to "this
and that keyword can be used her and there." I don't believe this is
good.

Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438

Then you should have a better idea what exactly will be allowed in future.

Please go over the list and tell me explicitly what I should revert there.

Secondly I'm among the people who read tons of "bad" code and I'm sure
people will abuse this and we will find code like this:

<?php
namespace network;
function if($which) {
// ... some logic ...
return "eth0";
}
// ... somewhere else in the namespace ...
if($condition);
?>

This can hide subtile typos or coding errors. Also look at currently
valid PHP code like this:

<?php
function while() {}
$condition = true;
while ($condition)
?>

and while reading this mind that an ; in front of an ?> is optional, so
will this call a function and exit or be stuck in an infinite loop?

I'm sure one could construct other such cases.

The "where (easily) possible" is exactly not this. To call here the function
while you would have to write namespace\while(); (or call_user_func etc.)
I explicitly tried to not change the things where might be such collisions.
(That's what I meant with the "(easily) possible".)
So this is basically a non-issue, I think, as it is highlighted that it's a function
and not a language construct by the need to prefix this.

I'm more open about allowing such identifiers as method names only, as
those are prefixed in some way ($object-> or someClass:: ) but even
there I tend to consider the consistency between function and method
names more important than this flexibility.

Yes, that is one of the main points.

I couldn't test those examples as your branch for some reason didn't
work, even though I made sure I regenerated the parser, but I didn't
look deeper, maybe my fault.
   001+ Parse error: syntax error, unexpected 'catch' (T_CATCH),
   expecting identifier (T_STRING) or \\ (T_NS_SEPARATOR) or '{'
   in /.../Zend/tests/identifier_or_keyword_001.php on line 3
   001- Ok
   002- Fatal error: %s in %s on line %d
johannes

This sounds like some error while you were patching, because I cannot
reproduce any such problem here.

Bob Weinand

11 years ago by johannes@schlueters.de — view source

unread

Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438

Then you should have a better idea what exactly will be allowed in future.

Please go over the list and tell me explicitly what I should revert there.

How would you teach that?

I'm sure one could construct other such cases.

The "where (easily) possible" is exactly not this. To call here the function
while you would have to write namespace\while(); (or call_user_func etc.)
I explicitly tried to not change the things where might be such collisions.
(That's what I meant with the "(easily) possible".)
So this is basically a non-issue, I think, as it is highlighted that it's a function
and not a language construct by the need to prefix this.

This, in my opinion, is a major inconsistency, mess and no-go.

I'm more open about allowing such identifiers as method names only, as
those are prefixed in some way ($object-> or someClass:: ) but even
there I tend to consider the consistency between function and method
names more important than this flexibility.

Yes, that is one of the main points.

"Method names and properties can be made of keywords" is a rule I can
live with, that's teachable, in itself consistent and almost always
clearly readable. (exceptions are already unreadable code)
I still have doubts about the inconsistency between function and method
names then, which is why I'd be on -0.5.

I couldn't test those examples as your branch for some reason didn't
work, even though I made sure I regenerated the parser, but I didn't
look deeper, maybe my fault.

This sounds like some error while you were patching, because I cannot
reproduce any such problem here.

as said: could be my fault :)

johannes

11 years ago by Bob Weinand — view source

unread

Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johannes@schlueters.de:

Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438

Then you should have a better idea what exactly will be allowed in future.

Please go over the list and tell me explicitly what I should revert there.

How would you teach that?

They're all keywords which depend on a keyword before while between them
can be an unlimited number of statements.

E.g. … T_ELSE statement_list T_ENDIF ';'
that's why a T_ENDIF doesn't work at the beginning of an expression

I'm sure one could construct other such cases.

The "where (easily) possible" is exactly not this. To call here the function
while you would have to write namespace\while(); (or call_user_func etc.)
I explicitly tried to not change the things where might be such collisions.
(That's what I meant with the "(easily) possible".)
So this is basically a non-issue, I think, as it is highlighted that it's a function
and not a language construct by the need to prefix this.

This, in my opinion, is a major inconsistency, mess and no-go.

We have basically the choice:
a) reject this patch
b) just allow classes/traits/interfaces/goto-label/method to change, but no funcs/ns
c) accept the whole patch

I'm more open about allowing such identifiers as method names only, as
those are prefixed in some way ($object-> or someClass:: ) but even
there I tend to consider the consistency between function and method
names more important than this flexibility.

Yes, that is one of the main points.

"Method names and properties can be made of keywords" is a rule I can
live with, that's teachable, in itself consistent and almost always
clearly readable. (exceptions are already unreadable code)
I still have doubts about the inconsistency between function and method
names then, which is why I'd be on -0.5.

johannes

Bob Weinand

11 years ago by Jakub Zelenka — view source

unread

Hi,

We have basically the choice:
a) reject this patch
b) just allow classes/traits/interfaces/goto-label/method to change, but
no funcs/ns
c) accept the whole patch

I think that goto-labels have similar issue as functions. Consider label

else:

Jakub

11 years ago by Bob Weinand — view source

unread

Am 13.9.2013 um 14:56 schrieb Jakub Zelenka bukka@php.net:

Hi,

We have basically the choice:
a) reject this patch
b) just allow classes/traits/interfaces/goto-label/method to change, but
no funcs/ns
c) accept the whole patch

I think that goto-labels have similar issue as functions. Consider label

else:

Jakub

else::constant; doesn't work too. that's why I've put goto-labels in the same
category like classes etc.

Bob Weinand

11 years ago by Jakub Zelenka — view source

unread

else::constant; doesn't work too. that's why I've put goto-labels in the
same
category like classes etc.

See also: https://github.com/php/php-src/pull/438

Bob Weinand

Oh I see, T_ELSE is not a component of inner_keyword and cannot be reduced
to identifier_or_inner_keyword though.

Sorry I should have looked on the patch before sending that silly comment.
:)

Jakub

11 years ago by johannes@schlueters.de — view source

unread

Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johannes@schlueters.de:

Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438

Then you should have a better idea what exactly will be allowed in future.

Please go over the list and tell me explicitly what I should revert there.

How would you teach that?

They're all keywords which depend on a keyword before while between them
can be an unlimited number of statements.

E.g. … T_ELSE statement_list T_ENDIF ';'
that's why a T_ENDIF doesn't work at the beginning of an expression

Consider Average Joe trying to extend some application, so he writes

<?php
namespace someApp\Actions;
function default() {
}
function secondary() {
}
function another() {
// ...
secondary();
// ...
}

namespace someApp\Controller;
function foo() {
someApp\Actions\default();
}

now a year later Programmer Smith comes along and changes this

<?php
namespace someApp\Actions;
function new() {
if ($condition) {
secondary();
} else {
default();
}
}

and will have a hard time to understand.

I'm sure one could construct other such cases.

The "where (easily) possible" is exactly not this. To call here the function
while you would have to write namespace\while(); (or call_user_func etc.)
I explicitly tried to not change the things where might be such collisions.
(That's what I meant with the "(easily) possible".)
So this is basically a non-issue, I think, as it is highlighted that it's a function
and not a language construct by the need to prefix this.

This, in my opinion, is a major inconsistency, mess and no-go.

We have basically the choice:
a) reject this patch
b) just allow classes/traits/interfaces/goto-label/method to change, but no funcs/ns
c) accept the whole patch

Option b) might also include class constants, I think. If we really want
this I'd still suggest to limit it to method names (and maybe class
constants) first as those are always properly scoped and then for a
later version evaluate the amount of (ab)use (as much as we can see
that ..), the headache for tools (code analyzers, IDEs, ..) and then
probably extend it.

If it's my own free choice I wouldn't add it at all.

johannes

11 years ago by Bob Weinand — view source

unread

Am 13.9.2013 um 15:31 schrieb Johannes Schlüter johannes@schlueters.de:

Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johannes@schlueters.de:

Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438

Then you should have a better idea what exactly will be allowed in future.

Please go over the list and tell me explicitly what I should revert there.

How would you teach that?

They're all keywords which depend on a keyword before while between them
can be an unlimited number of statements.

E.g. … T_ELSE statement_list T_ENDIF ';'
that's why a T_ENDIF doesn't work at the beginning of an expression

Consider Average Joe trying to extend some application, so he writes

<?php
namespace someApp\Actions;
function default() {
}
function secondary() {
}
function another() {
// ...
secondary();
// ...
}

namespace someApp\Controller;
function foo() {
someApp\Actions\default();
}

now a year later Programmer Smith comes along and changes this

<?php
namespace someApp\Actions;
function new() {
if ($condition) {
secondary();
} else {
default();
}
}

and will have a hard time to understand.

Agree.

I'm sure one could construct other such cases.

The "where (easily) possible" is exactly not this. To call here the function
while you would have to write namespace\while(); (or call_user_func etc.)
I explicitly tried to not change the things where might be such collisions.
(That's what I meant with the "(easily) possible".)
So this is basically a non-issue, I think, as it is highlighted that it's a function
and not a language construct by the need to prefix this.

This, in my opinion, is a major inconsistency, mess and no-go.

We have basically the choice:
a) reject this patch
b) just allow classes/traits/interfaces/goto-label/method to change, but no funcs/ns
c) accept the whole patch

Option b) might also include class constants, I think. If we really want
this I'd still suggest to limit it to method names (and maybe class
constants) first as those are always properly scoped and then for a
later version evaluate the amount of (ab)use (as much as we can see
that ..), the headache for tools (code analyzers, IDEs, ..) and then
probably extend it.

If it's my own free choice I wouldn't add it at all.

johannes

I think we should choose option b). Yes; forgot to list the class constants.

Will remove support for unlimited function names etc. then tomorrow if no-one has a
better idea.

What then would be still supported exactly is
with the restricted list:

typehint
class/trait/interface names
goto-label

unrestricted:

method names
constant names
property names
trait aliases
declare list
(- argument names if we use identifier => $value syntax for named args)

I think this is a good compromise.

Bob Weinand

11 years ago by Bob Weinand — view source

unread

Am 13.9.2013 um 16:18 schrieb Bob Weinand bobwei9@hotmail.com:

What then would be still supported exactly is
with the restricted list:

typehint

class/trait/interface names

goto-label

unrestricted:

method names

constant names

property names

trait aliases

declare list
(- argument names if we use identifier => $value syntax for named args)

I think this is a good compromise.

As promised I updated my patch. Think it is now less inconsistent.

Are there still any issues now?

Bob Weinand

11 years ago by Pierre Joye — view source

unread

Hi,

Am 13.9.2013 um 16:18 schrieb Bob Weinand bobwei9@hotmail.com:

What then would be still supported exactly is
with the restricted list:

typehint

class/trait/interface names

goto-label

unrestricted:

method names

constant names

property names

trait aliases

declare list
(- argument names if we use identifier => $value syntax for named args)

I think this is a good compromise.

As promised I updated my patch. Think it is now less inconsistent.

Are there still any issues now?

Thanks for your work!

Did you update the patch according to Johannes suggestions?

I think we need a RFC for this non trivial change (from a user land point
of view and to change the engine). Do you know how to proceed to create one?

Cheers,

11 years ago by Bob Weinand — view source

unread

Am 14.9.2013 um 23:21 schrieb Pierre Joye pierre.php@gmail.com:

Hi,

Am 13.9.2013 um 16:18 schrieb Bob Weinand bobwei9@hotmail.com:

What then would be still supported exactly is
with the restricted list:

typehint

class/trait/interface names

goto-label

unrestricted:

method names

constant names

property names

trait aliases

declare list
(- argument names if we use identifier => $value syntax for named args)

I think this is a good compromise.

As promised I updated my patch. Think it is now less inconsistent.

Are there still any issues now?

Thanks for your work!

Did you update the patch according to Johannes suggestions?

I think we need a RFC for this non trivial change (from a user land point of view and to change the engine). Do you know how to proceed to create one?

If I didn't misunderstand Johannes, I have changed the patch to what he suggested.

I will now proceed to write a RFC. Shouldn't be too complicated I think. If I'll encounter some problems, I'll come back here.

Bob Weinand

11 years ago by Bob Weinand — view source

unread

Am 14.09.2013 um 23:21 schrieb "Pierre Joye" pierre.php@gmail.com:

I think we need a RFC for this non trivial change (from a user land point
of view and to change the engine). Do you know how to proceed to create one?

I now created the RFC:

https://wiki.php.net/rfc/keywords_as_identifiers

Bob Weinand

11 years ago by Pierre Joye — view source

unread

hi Bob!

Am 14.09.2013 um 23:21 schrieb "Pierre Joye" pierre.php@gmail.com:

I think we need a RFC for this non trivial change (from a user land point
of view and to change the engine). Do you know how to proceed to create one?

I now created the RFC:

https://wiki.php.net/rfc/keywords_as_identifiers

Thanks!

A last thing for this step is required, please create a new thread
called "[RFC] keywords_as_identifiers" and you should be good :)

Check out https://wiki.php.net/rfc/voting for the other information.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Daniel Convissor — view source

unread

Hi Bob:

I tried to widen the naming possibilities by allowing to use keywords
as identifiers (for function names, class names, label (goto) names,
...) where possible.

Thank you for putting energy in to enhancing PHP.

That said, implementing this particular proposal will make code harder
to read and debug.

-1

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335

11 years ago by Bob Weinand — view source

unread

Am 17.9.2013 um 16:27 schrieb Daniel Convissor danielc@analysisandsolutions.com:

Hi Bob:

I tried to widen the naming possibilities by allowing to use keywords
as identifiers (for function names, class names, label (goto) names,
...) where possible.

Thank you for putting energy in to enhancing PHP.

That said, implementing this particular proposal will make code harder
to read and debug.

-1

--Dan

Hi,

It's now only for class/interface/trait, label and method names. Don't see a
reason why this should make PHP harder to debug with an appropriate
syntax highlighting editor.

You could also argue that the current $obj->default; (that's already possible)
is also bad.

Bob Weinand

11 years ago by Marco Pivetta — view source

unread

You could also argue that the current $obj->default; (that's already
possible)
is also bad.

Yep, and should probably be removed.
It's still there because of BC compatibility as far as I know...

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

11 years ago by Igor Wiedler — view source

unread

Hi Bob,

Thanks for working on this.

The amount of reserved keywords in PHP is quite large and I've experienced many cases where it would have been useful to use them. Especially when implementing a DSL, parser, code generator (quite common use case with template engines, and various other tools), this is often an issue.

The engine supports those "reserved" names without issues, and you can often actually support them by subverting the parser. As such, supporting them directly makes sense to me.

Regards,

Igor

11 years ago by Daniel Convissor — view source

unread

Hi Bob:

It's now only for class/interface/trait, label and method names.

Sure, that's not as bad.

A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run on older PHP versions. That cost
seems greater than the benefit of some developers being able to call
$o->default() instead of $o->get_default().

Thanks for your consideration,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335

11 years ago by Bob Weinand — view source

unread

Am 18.9.2013 um 19:53 schrieb Daniel Convissor danielc@analysisandsolutions.com:

Hi Bob:

It's now only for class/interface/trait, label and method names.

Sure, that's not as bad.

A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run on older PHP versions. That cost
seems greater than the benefit of some developers being able to call
$o->default() instead of $o->get_default().

Thanks for your consideration,

--Dan

Well, that makes no sense. Then you just could say no to all new language changes.
Because it cannot be run on older versions. (yes, you CAN change the hoster if he
doesn't provide the newest PHP version, or (when you have the rights to) just upgrade
it yourself.)

This is really a non-argument.

Bob Weinand

11 years ago by Daniel Convissor — view source

unread

Hi Bob:

Well, that makes no sense. Then you just could say no to all new
language changes. Because it cannot be run on older versions.

Allow me one last post to clarify. What I said is the cost in this
case doesn't outweigh the advantages.

As someone who writes a lot of open source (and proprietary) code that
gets run on machines that I have no control over, implementing this
proposal will complicate my life. Every time I make a function I'll
have to ask myself "is this a reserved word in older versions of PHP?"

I'll leave the discussion at that.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335

11 years ago by Martin Nicholls — view source

unread

Allow me one last post to clarify. What I said is the cost in this
case doesn't outweigh the advantages. As someone who writes a lot of
open source (and proprietary) code that gets run on machines that I
have no control over, implementing this proposal will complicate my
life. Every time I make a function I'll have to ask myself "is this a
reserved word in older versions of PHP?" I'll leave the discussion at
that.

You're going to have to ask that question anyway. It's not a good reason
to not do it. As some point you're not going to be wanting to support
ancient PHP versions and you'll be able to do what you like. Continue
as-is like there was no change and you'll never have an issue. There's
no cost.

Regards

11 years ago by Madara Uchiha — view source

unread

Hi Bob:

Well, that makes no sense. Then you just could say no to all new
language changes. Because it cannot be run on older versions.

Allow me one last post to clarify. What I said is the cost in this
case doesn't outweigh the advantages.

As someone who writes a lot of open source (and proprietary) code that
gets run on machines that I have no control over, implementing this
proposal will complicate my life. Every time I make a function I'll
have to ask myself "is this a reserved word in older versions of PHP?"

I'll leave the discussion at that.

Thanks,

--Dan

Really? Really?! If you don't want to use (un)reserved keywords, just
don't, regardless of if it's allowed in PHPX and not in PHPY, why do
you care if it's implemented for those who do want it available?

11 years ago by Kristopher — view source

unread

On Wed, Sep 18, 2013 at 2:25 PM, Daniel Convissor <
danielc@analysisandsolutions.com> wrote:

As someone who writes a lot of open source (and proprietary) code that
gets run on machines that I have no control over, implementing this
proposal will complicate my life. Every time I make a function I'll
have to ask myself "is this a reserved word in older versions of PHP?"

You have to do this with any relatively new PHP feature (namespaces,
traits, generators, etc) that is implemented; how is this any different?

11 years ago by Pierre Joye — view source

unread

On Sep 18, 2013 10:53 AM, "Daniel Convissor" <
danielc@analysisandsolutions.com> wrote:

Hi Bob:

It's now only for class/interface/trait, label and method names.

Sure, that's not as bad.

A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run on older PHP versions. That cost
seems greater than the benefit of some developers being able to call
$o->default() instead of $o->get_default().

Thanks for your consideration,

Well, it is a good point but impossible to keep without killing any future
language improvements. Think of generators f.e.

11 years ago by Bob Weinand — view source

unread

I plan to move this rfc forward to voting phase in the next days.

I have made some (huge) changes to the initial implementation over the last weeks.

There initially was the problem that there were some ugly restrictions which keywords are allowed under which circumstances.
They are now resolved (= all keywords possible except the ones which conflict with existing functionality).

If there aren't any further objections now, I'll move it to voting phase.

Bob Weinand

Am 11.9.2013 um 23:21 schrieb Bob Weinand bobwei9@hotmail.com:

Hi!

I tried to widen the naming possibilities by allowing to use keywords as identifiers (for function names, class names, label (goto) names, ...) where possible. It doesn't break any BC.

Furthermore when BC needs to be broken in future for new keywords, it will have a smaller impact as most usages of the new keyword then still work.

It also prevents unnecessary workarounds like in https://wiki.php.net/rfc/named_params#syntax. There, to address a function with a parameter called $array, we could simply write func(array => $value); instead of the until now necessary func("array" => value);

You can find the patch here:
https://github.com/php/php-src/pull/438

Any thoughts about this?

Bob Weinand