# Support for keywords where possible

- Thread: https://externals.io/message/69068
- Original archive: https://news-web.php.net/php.internals/69068
- Started by Bob Weinand on 2013-09-11T21:21:05+00:00
- Messages: 40
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/69068.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #69068 — Bob Weinand — 2013-09-11T21:21:05+00:00

URL: https://externals.io/message/69068#69068

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

---

## #69079 — Lazare Inepologlou — 2013-09-12T06:43:30+00:00

URL: https://externals.io/message/69068#69079 · In reply to: #69068

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

---

## #69080 — Benjamin Eberlei — 2013-09-12T07:04:50+00:00

URL: https://externals.io/message/69068#69080 · In reply to: #69068

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

---

## #69081 — Ryan McCue — 2013-09-12T07:09:05+00:00

URL: https://externals.io/message/69068#69081 · In reply to: #69068

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/

---

## #69082 — Michael Wallner — 2013-09-12T07:10:44+00:00

URL: https://externals.io/message/69068#69082 · In reply to: #69068

> 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

---

## #69094 — Bob Weinand — 2013-09-12T12:56:42+00:00

URL: https://externals.io/message/69068#69094 · In reply to: #69082

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

> 
> > […]
> 
> 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

---

## #69096 — Michael Wallner — 2013-09-12T13:06:28+00:00

URL: https://externals.io/message/69068#69096 · In reply to: #69094

> 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

---

## #69097 — Benjamin Eberlei — 2013-09-12T13:12:10+00:00

URL: https://externals.io/message/69068#69097 · In reply to: #69096

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




> 
> > […]
> strncasecmp needs to be used)
>
> Is there a number missing after "JUST"?
>
> > […]
>
> What random files?
>
> > […]
> 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

---

## #69098 — Bob Weinand — 2013-09-12T14:34:40+00:00

URL: https://externals.io/message/69068#69098 · In reply to: #69096

Am 12.9.2013 um 15:06 schrieb Michael Wallner <mike@php.net>:
> 
> > […]
> 
> Is there a number missing after "JUST"?

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

> > […]
> 
> What random files?

Some PHP files that were on my server

> > […]
> 
> 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

---

## #69099 — Michael Wallner — 2013-09-12T14:49:12+00:00

URL: https://externals.io/message/69068#69099 · In reply to: #69098

> 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

---

## #69102 — Pierre Joye — 2013-09-12T16:18:41+00:00

URL: https://externals.io/message/69068#69102 · In reply to: #69098

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

---

## #69104 — johannes@schlueters.de — 2013-09-12T20:44:29+00:00

URL: https://externals.io/message/69068#69104 · In reply to: #69068

> 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:

    <?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.

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

---

## #69105 — Nikita Popov — 2013-09-12T20:55:51+00:00

URL: https://externals.io/message/69068#69105 · In reply to: #69104

On Thu, Sep 12, 2013 at 10:44 PM, Johannes Schlüter
<johannes@schlueters.de>wrote:

> 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:
>
>     <?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.
>
> 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

---

## #69106 — Pierre Joye — 2013-09-12T20:59:56+00:00

URL: https://externals.io/message/69068#69106 · In reply to: #69105

> 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

---

## #69110 — Bob Weinand — 2013-09-12T23:24:48+00:00

URL: https://externals.io/message/69068#69110 · In reply to: #69104

Am 12.9.2013 um 22:44 schrieb Johannes Schlüter <johannes@schlueters.de>:
> 
> > […]
> 
> 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

---

## #69111 — Bob Weinand — 2013-09-12T23:34:55+00:00

URL: https://externals.io/message/69068#69111 · In reply to: #69106

Am 12.9.2013 um 22:59 schrieb Pierre Joye <pierre.php@gmail.com>:
> 
> > […]

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

---

## #69114 — johannes@schlueters.de — 2013-09-13T09:48:12+00:00

URL: https://externals.io/message/69068#69114 · In reply to: #69110

> 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?


> > […]
> 
> 
> 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.

> > […]
> 
> 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.

> > […]

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

as said: could be my fault :)

johannes

---

## #69115 — Bob Weinand — 2013-09-13T12:39:36+00:00

URL: https://externals.io/message/69068#69115 · In reply to: #69114

Am 13.9.2013 um 11:48 schrieb Johannes Schlüter <johannes@schlueters.de>:
> 
> > […]
> 
> 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

> > […]
> 
> 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

> > […]
> 
> "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

---

## #69116 — Jakub Zelenka — 2013-09-13T12:56:59+00:00

URL: https://externals.io/message/69068#69116 · In reply to: #69115

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

---

## #69117 — Bob Weinand — 2013-09-13T13:03:48+00:00

URL: https://externals.io/message/69068#69117 · In reply to: #69116

Am 13.9.2013 um 14:56 schrieb Jakub Zelenka <bukka@php.net>:
> Hi,
> 
> 
> > […]
> 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.

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

Bob Weinand

---

## #69118 — Jakub Zelenka — 2013-09-13T13:29:03+00:00

URL: https://externals.io/message/69068#69118 · In reply to: #69117

>
> 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

---

## #69119 — johannes@schlueters.de — 2013-09-13T13:31:38+00:00

URL: https://externals.io/message/69068#69119 · In reply to: #69115

> Am 13.9.2013 um 11:48 schrieb Johannes Schlüter <johannes@schlueters.de>:
> > […]
> 
> 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.

> > […]
> 
> 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

---

## #69120 — Bob Weinand — 2013-09-13T14:18:06+00:00

URL: https://externals.io/message/69068#69120 · In reply to: #69119

Am 13.9.2013 um 15:31 schrieb Johannes Schlüter <johannes@schlueters.de>:
> 
> > […]
> 
> 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.

> > […]
> 
> 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

---

## #69129 — Bob Weinand — 2013-09-14T17:56:41+00:00

URL: https://externals.io/message/69068#69129 · In reply to: #69120

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

---

## #69130 — Pierre Joye — 2013-09-14T21:21:33+00:00

URL: https://externals.io/message/69068#69130 · In reply to: #69129

Hi,

>
> Am 13.9.2013 um 16:18 schrieb Bob Weinand <bobwei9@hotmail.com>:
> > […]
>
>
> 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,

---

Next page: https://externals.io/message/69068.md?page=2