Hi internals!
Voting has opened for the inclusion of a digit separator in PHP1. Voting ends in
one week's time on January 20th.
Thanks,
Tom
Hi Thomas,
Thomas Punt wrote:
Hi internals!
Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends in
one week's time on January 20th.Thanks,
Tom
Initially I was going to abstain from this vote, but I've changed my
mind and I am now voting in favour of the RFC.
When choosing whether to add features to the language, we must set a
high standard, because every new additions means additional complexity
and more knowledge PHP developers have to have. So, every new addition
should be made to fit well with existing features, be useful, and
This feature offers some benefit in some cases. It doesn't introduce
much new complexity. There's no new syntax or tokens, it just modifies
the form of the existing number tokens. It fits in well what's already
there, consistently applying to all number literals. It follows
established convention in other languages. Its appearance at least hints
that values with these seperators are not constants or identifiers, but
numbers, reducing potential for confusion. It limits its own application
to prevent abuse (no leading, trailing, or repeated separators). And
it's relatively intuitive.
So I think it might be worth adding, thus my vote. Though we must be
conservative with additions, this one doesn't seem to be too problematic.
That said, I might be voting the wrong way. The feature does seem to
have limited applicability. That's really the only thing I can say
against it.
Thanks.
--
Andrea Faulds
https://ajf.me/
Hi all,
Thomas Punt wrote:
Hi internals!
Voting has opened for the inclusion of a digit separator in PHP1. Voting
ends in
one week's time on January 20th.Thanks,
TomInitially I was going to abstain from this vote, but I've changed my mind
and I am now voting in favour of the RFC.When choosing whether to add features to the language, we must set a high
standard, because every new additions means additional complexity and more
knowledge PHP developers have to have. So, every new addition should be made
to fit well with existing features, be useful, andThis feature offers some benefit in some cases. It doesn't introduce much
new complexity. There's no new syntax or tokens, it just modifies the form
of the existing number tokens. It fits in well what's already there,
consistently applying to all number literals. It follows established
convention in other languages. Its appearance at least hints that values
with these seperators are not constants or identifiers, but numbers,
reducing potential for confusion. It limits its own application to prevent
abuse (no leading, trailing, or repeated separators). And it's relatively
intuitive.So I think it might be worth adding, thus my vote. Though we must be
conservative with additions, this one doesn't seem to be too problematic.That said, I might be voting the wrong way. The feature does seem to have
limited applicability. That's really the only thing I can say against it.
The same opinion.
The syntax is popular enough and doesn't add much complexity, but
it seems this RFC wouldn't pass.
Large numeric literals are not used often. However if it is used, it's
frustrating to read. e.g. Code audit/review. Why not make computer
do the job?
I hope more people change their mind.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Large numeric literals are not used often. However if it is used, it's
frustrating to read. e.g. Code audit/review. Why not make computer
do the job?I hope more people change their mind.
Where large numbers are used, adding them as strings using the local
format is already used? This just adds yet another 'option' to how they
can be entered but is something which makes reading in the context of
the local use MORE of a problem? My main need would be hexadecimal code
which is not covered, so I still need the alternate hacks anyway.
--
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
My main need would be hexadecimal code
which is not covered, so I still need the alternate hacks anyway.
Hex is covered, see the first examples in the "Proposal" section
My main need would be hexadecimal code which is not covered, so I still need the alternate hacks anyway.Hex is covered, see the first examples in the "Proposal" section
Sorry getting mixed up ;)
Can't use the 0x in some areas, so one ends up with an alternate method
of adding the data as hex ... with it's own separator ... but for the
life of me I can't find why we had to do that now. This may be down to
BIGINT and 64bit numbers in databases ... that is where the data ends up
and I know the 0x was a problem - or was it octal input
--
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
Den 2016-01-18 kl. 13:22, skrev Lester Caine:
Large numeric literals are not used often. However if it is used, it's
frustrating to read. e.g. Code audit/review. Why not make computer
do the job?I hope more people change their mind.
Where large numbers are used, adding them as strings using the local
format is already used? This just adds yet another 'option' to how they
can be entered but is something which makes reading in the context of
the local use MORE of a problem? My main need would be hexadecimal code
which is not covered, so I still need the alternate hacks anyway.
Hm... I got the impression it was covered by reading the two last
examples of: "Enable for arbitrary grouping of digits". Did I read
it to quick?
r//Björn
Hi internals!
Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends in
one week's time on January 20th.
Voting has now ended with 20 for and 18 against. This means the RFC has been
declined.
Thank you to all who participated in the RFC discussion and voting!
-Tom