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
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 funct
>
> 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
Am 18.9.2013 um 19:53 schrieb Daniel Convissor
:
> 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. Th
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
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
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 a
On 17 September 2013 16:43, Bob Weinand 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
http://twitter.com/Ocramius
ht
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 tool
Am 17.9.2013 um 16:27 schrieb Daniel Convissor
:
> 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 sa
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
t
Am 14.9.2013 um 23:21 schrieb Pierre Joye :
> Hi,
> On Sep 14, 2013 10:56 AM, "Bob Weinand" wrote:
> >
> > Am 13.9.2013 um 16:18 schrieb Bob Weinand :
> > > What then would be still supported exactly is
> > > with the restricted list:
> > > - typehint
> > > - class/trait/interface names
> > > - go
Hi,
On Sep 14, 2013 10:56 AM, "Bob Weinand" wrote:
>
> Am 13.9.2013 um 16:18 schrieb Bob Weinand :
> > What then would be still supported exactly is
> > with the restricted list:
> > - typehint
> > - class/trait/interface names
> > - goto-label
> >
> > unrestricted:
> > - method names
> > - consta
Am 13.9.2013 um 16:18 schrieb Bob Weinand :
> 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
> (- argum
Am 13.9.2013 um 15:31 schrieb Johannes Schlüter :
> On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote:
>> Am 13.9.2013 um 11:48 schrieb Johannes Schlüter :
>>> On Fri, 2013-09-13 at 01:24 +0200, Bob Weinand wrote:
Here is a concrete list when keywords are allowed:
https://github.com/ph
On Fri, 2013-09-13 at 14:39 +0200, Bob Weinand wrote:
> Am 13.9.2013 um 11:48 schrieb Johannes Schlüter :
> > 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
>
> 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.
Am 13.9.2013 um 14:56 schrieb Jakub Zelenka :
> 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 functio
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 11:48 schrieb Johannes Schlüter :
> 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
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 reve
Am 12.9.2013 um 22:44 schrieb Johannes Schlüter :
> 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 br
Am 12.9.2013 um 22:59 schrieb Pierre Joye :
> On Thu, Sep 12, 2013 at 10:55 PM, Nikita Popov 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 support all keywords and b) it is
>>
On Thu, Sep 12, 2013 at 10:44 PM, Johannes Schlüter
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
On Thu, Sep 12, 2013 at 10:55 PM, Nikita Popov 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
> support only in
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
hi,
On Thu, Sep 12, 2013 at 4:34 PM, Bob Weinand 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
>
> Se
On 12 September 2013 16:34, Bob Weinand 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 that i
Am 12.9.2013 um 15:06 schrieb Michael Wallner :
> On 12 September 2013 14:56, Bob Weinand 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 1000
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 wrote:
> On 12 September 2013 14:56, Bob Weinand
On 12 September 2013 14:56, Bob Weinand 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
>
> Without patch:
>
Am 12.9.2013 um 09:10 schrieb Michael Wallner :
> On 11 September 2013 23:21, 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
On 11 September 2013 23:21, 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.
>
> Furthermore when BC needs to be broken in futu
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_STRI
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 wrote:
> Hi!
>
> I tried to widen the naming possibilities by allowing to
2013/9/11 Bob Weinand
> 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 wi
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
