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
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
On 18/09/2013 19:25, Daniel Convissor wrote:
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
Am 18.9.2013 um 19:53 schrieb Daniel Convissor
dani...@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
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
On Wed, Sep 18, 2013 at 2:25 PM, Daniel Convissor
dani...@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
On Sep 18, 2013 10:53 AM, Daniel Convissor
dani...@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
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
Am 17.9.2013 um 16:27 schrieb Daniel Convissor
dani...@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
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
On 17 September 2013 16:43, Bob Weinand bobw...@hotmail.com wrote:
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
Am 13.9.2013 um 16:18 schrieb Bob Weinand bobw...@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
Hi,
On Sep 14, 2013 10:56 AM, Bob Weinand bobw...@hotmail.com wrote:
Am 13.9.2013 um 16:18 schrieb Bob Weinand bobw...@hotmail.com:
What then would be still supported exactly is
with the restricted list:
- typehint
- class/trait/interface names
- goto-label
unrestricted:
- method
Am 14.9.2013 um 23:21 schrieb Pierre Joye pierre@gmail.com:
Hi,
On Sep 14, 2013 10:56 AM, Bob Weinand bobw...@hotmail.com wrote:
Am 13.9.2013 um 16:18 schrieb Bob Weinand bobw...@hotmail.com:
What then would be still supported exactly is
with the restricted list:
- typehint
-
On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
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
Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
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.
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
Am 13.9.2013 um 14:56 schrieb Jakub Zelenka bu...@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.
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
On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote:
Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
Here is a concrete list when keywords are allowed:
https://github.com/php/php-src/pull/438
Then you should
Am 13.9.2013 um 15:31 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote:
Am 13.9.2013 um 11:48 schrieb Johannes Schlüter johan...@schlueters.de:
On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
Here is a concrete list when keywords are
2013/9/11 Bob Weinand bobw...@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
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
On Wed, Sep 11, 2013 at 11:21 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi!
I tried to widen the naming
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
On 11 September 2013 23:21, Bob Weinand bobw...@hotmail.com wrote:
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
Am 12.9.2013 um 09:10 schrieb Michael Wallner m...@php.net:
On 11 September 2013 23:21, Bob Weinand bobw...@hotmail.com wrote:
Hi!
I tried to widen the naming possibilities by allowing to use keywords as
identifiers (for function names, class names, label (goto) names, ...) where
On 12 September 2013 14:56, Bob Weinand bobw...@hotmail.com wrote:
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 1 iterations: 8.6687519550323 seconds
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
On Thu, Sep 12, 2013 at 3:06 PM, Michael Wallner m...@php.net wrote:
On 12 September 2013 14:56,
Am 12.9.2013 um 15:06 schrieb Michael Wallner m...@php.net:
On 12 September 2013 14:56, Bob Weinand bobw...@hotmail.com wrote:
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
On 12 September 2013 16:34, Bob Weinand bobw...@hotmail.com wrote:
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
hi,
On Thu, Sep 12, 2013 at 4:34 PM, Bob Weinand bobw...@hotmail.com wrote:
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
On Wed, 2013-09-11 at 23:21 +0200, Bob Weinand wrote:
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
On Thu, Sep 12, 2013 at 10:55 PM, Nikita Popov nikita@gmail.com wrote:
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
On Thu, Sep 12, 2013 at 10:44 PM, Johannes Schlüter
johan...@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
Am 12.9.2013 um 22:59 schrieb Pierre Joye pierre@gmail.com:
On Thu, Sep 12, 2013 at 10:55 PM, Nikita Popov nikita@gmail.com wrote:
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
Am 12.9.2013 um 22:44 schrieb Johannes Schlüter johan...@schlueters.de:
On Wed, 2013-09-11 at 23:21 +0200, Bob Weinand wrote:
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.
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
37 matches
Mail list logo
