On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote:
He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being requested (ie. possible
on windows using meta info), or keep everything the
On Thu, Dec 25, 2014 at 9:05 PM, Alain Williams a...@phcomp.co.uk wrote:
On Thu, Dec 25, 2014 at 04:40:09AM +0100, François Laupretre wrote:
He will also have to deal with
file ops while being at it. Should they remain case insensitive? Do
manual checks to match the path actually being
On Thu, Dec 25, 2014 at 10:18:13PM +1100, Pierre Joye wrote:
Forgot reply all? :)
Yes - thanks. Reformatted:
On Thu, Dec 25, 2014 at 09:53:11PM +1100, Pierre Joye wrote:
I do not see a reason why some code having ran out of the box for more
than a decade should be changed for 7 for purely
On Thu, Dec 25, 2014 at 4:40 AM, François Laupretre franc...@tekwire.net
wrote:
De : Pierre Joye [mailto:pierre@gmail.com]
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC.
For those interested, I just created a PR to raise
On Dec 25, 2014 7:08 PM, Nikita Popov nikita@gmail.com wrote:
May I recommend to only target class and class-like names for an initial
RFC? Those have the strongest argument in favor of case-sensitivity given
how current autoloader implementations work - essentially the
case-insensitivity
Fixed.
http://git.php.net/?p=web/php.git;a=commitdiff;h=52cb11fca4c343f0529ceecfdc5372b49b966435
(should be refreshed on the website soon enough)
On Wed, Dec 24, 2014 at 6:58 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
http://php.net/ChangeLog-5.php#5.4.36
does not mention
Good evening and merry christmas,
After some discussion in a separated thread I created the RFC to discuss
about the implementation of another json_encode option.
The RFC can be found here:
https://wiki.php.net/rfc/json_preserve_fractional_part
Juan Basso
On 25 Dec 2014, at 19:32, Juan Basso jrba...@gmail.com wrote:
Good evening and merry christmas,
After some discussion in a separated thread I created the RFC to discuss
about the implementation of another json_encode option.
The RFC can be found here:
On Thu, Dec 25, 2014 at 9:05 PM, Andrea Faulds a...@ajf.me wrote:
On 25 Dec 2014, at 19:32, Juan Basso jrba...@gmail.com wrote:
Good evening and merry christmas,
After some discussion in a separated thread I created the RFC to discuss
about the implementation of another json_encode
There's already ZEND_RESULT_CODE, or did I miss anything?
On 25 Dec 2014 06:45, Xinchen Hui larue...@php.net wrote:
Hey:
On Thu, Dec 25, 2014 at 12:38 PM, Pierre Joye pierre@gmail.com
wrote:
On Thu, Dec 25, 2014 at 3:06 PM, Andrea Faulds a...@ajf.me wrote:
On 24 Dec 2014, at 23:53,
Hi!
Good evening and merry christmas,
After some discussion in a separated thread I created the RFC to discuss
about the implementation of another json_encode option.
The RFC can be found here:
https://wiki.php.net/rfc/json_preserve_fractional_part
Completely makes sense for me as an
Hi!
At the very least that sounds like a less intrusive step, as methods and
classes are usually already written correctly.
To me, it sounds like needless nuisance - the code works, but wastes
time to produce warnings that nobody reads. If your have a code that
relies on autoloaders and case
Exactly. The idea of this RFC is just to add as a new option and not
enabled by default.
The idea to enable it by default was discussed before and I just added as
future scope since it is not an easy decision, especially because the
backward compatibility. The main goal is to have the option to
On 25 Dec 2014, at 19:32, Juan Basso jrba...@gmail.com wrote:
The RFC can be found here:
https://wiki.php.net/rfc/json_preserve_fractional_part
Hey Juan,
A further thought: is “Preserve Fractional Part” the best name? Integral floats
like float(12) don’t have any fractional part, and
Andrea,
I am not a specialist in float numbers, but I think integral float numbers
have a fractional part with value 0.
JSON_FLOAT_ADD_POINT_ZERO can be confuse for regular floats with non-zero
as fractional part. Seems you are going to add a point zero in a regular
float with point something.
On Dec 26, 2014 4:58 AM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
At the very least that sounds like a less intrusive step, as methods and
classes are usually already written correctly.
To me, it sounds like needless nuisance - the code works, but wastes
time to produce warnings
On Fri, Dec 26, 2014 at 8:33 AM, Michael Wallner m...@php.net wrote:
There's already ZEND_RESULT_CODE, or did I miss anything?
Yes, to read the thread :)
We are not talking about the lack of a status typedef but about the
inconsistencies across PHP internal APIs. And what Xinchen suggests
below
On Mon, Nov 24, 2014 at 8:47 PM, Sara Golemon poll...@php.net wrote:
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a
On Fri, Dec 26, 2014 at 1:20 PM, Sara Golemon poll...@php.net wrote:
On Mon, Nov 24, 2014 at 8:47 PM, Sara Golemon poll...@php.net wrote:
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for
On Thu, Dec 25, 2014 at 2:33 PM, Michael Wallner m...@php.net wrote:
There's already ZEND_RESULT_CODE, or did I miss anything?
According to lxr.php.net, this symbol ZEND_RESULT_CODE is not
referenced in any place except its definition. We can begin using it
if we like, or even rename it.
Hey:
On Fri, Dec 26, 2014 at 5:33 AM, Michael Wallner m...@php.net wrote:
There's already ZEND_RESULT_CODE, or did I miss anything?
yes,
we were talking about use ZEND_RESULT_CODE as return type hinting for
those functions use SUCCSS/FAILURE ..
furthermore, maybe we could use it as all
21 matches
Mail list logo
