Re: [PHP-DEV] [RFC] JSON number to string

> On 25 May 2015, at 18:40, Jakub Zelenka wrote: > >> Anyway, as I told in a previous thread, while approach of this rfc solves >> immediate problem, it is not future-proof flexible and exposing low-level >> type based parsing is a better idea >> > IIRC your initial proposal was about convert

[PHP-DEV] Re: Exception message cleanup

On Thu, Apr 9, 2015 at 10:04 AM, Nikita Popov wrote: > Hi internals! > > A lot of people have been confused about engine exceptions currently > displaying as normal fatal errors (if they aren't caught). We'll have to > change this to use exception messages. > > Before doing this I'd like to clean

Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

> There was some discussion on contant arrays on Stackoverflow with an > answer by Andrea Faulds (with a link to changes between 5.6 and 7.0): > http://stackoverflow.com/a/27413238/872051 Ok, thank. Why the speed of access to const the array ARR['key'] is 500% slower, in comparison with the varia

Re: [PHP-DEV] [RFC] Throwable Interface

On 24/05/2015 22:32, Yasuo Ohgaki wrote: Does this include internal function type errors? e.g. $ php -r 'var_dump(mt_srand("999"));' PHP Warning: mt_srand() expects parameter 1 to be integer, string given in Command line code on line 1 NULL If not, please make t

Re: [PHP-DEV] ::class wrong case

On Mon, 25 May 2015 20:47:32 +0300, Marc Bennewitz wrote: Hi, I have noted that detecting a class name using "::class" it will return the called case instead of the original case. see http://3v4l.org/97K36 That's annoying as I like to check the right class case on autoload to detect mist

Re: [PHP-DEV] ::class wrong case

On Mon, May 25, 2015 at 11:47 AM, Marc Bennewitz wrote: > Hi, > > I have noted that detecting a class name using "::class" it will return the > called case instead of the original case. > see http://3v4l.org/97K36 > > That's annoying as I like to check the right class case on autoload to > detect

Re: [PHP-DEV] [RFC] Throwable Interface

On 05/24/2015 11:32 PM, Yasuo Ohgaki wrote: Hi Aaron, On Sun, May 24, 2015 at 5:12 AM, Aaron Piotrowski wrote: I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding Throwable interface and renaming the exceptions thrown from fatal errors. The RFC is now ready for discu

Re: [PHP-DEV] [RFC] Throwable Interface

On 05/24/2015 10:11 PM, Aaron Piotrowski wrote: On May 24, 2015, at 2:08 PM, Marc Bennewitz wrote: Where are the new classes and the interface located if it's not in the global namespace or do I muss something? Sorry if what I wrote wasn’t clear. Throwable, Error, TypeError, and ParseErro

[PHP-DEV] ::class wrong case

Hi, I have noted that detecting a class name using "::class" it will return the called case instead of the original case. see http://3v4l.org/97K36 That's annoying as I like to check the right class case on autoload to detect mistakes. Sure, class names in PHP are case-insensitive but files

Re: [PHP-DEV] [RFC] JSON number to string

Hi, On Mon, May 25, 2015 at 7:59 AM, Alexey Zakhlestin wrote: > > > I'm not sure how JSON Schema would help here. The issue is about > converting from json's huge numbers to limited PHP's numbers. Schema just > doesn't have notion of native types > > The idea would be to use JSON schema to specif

Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

"S.A.N" in php.internals (Mon, 25 May 2015 16:09:42 +0300): >> It is by design; the documentation states[1]: >> >> | isset() only works with variables as passing anything else will >> | result in a parse error. >> >> [1] >>

Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

> It is by design; the documentation states[1]: > > | isset() only works with variables as passing anything else will > | result in a parse error. > > [1] > Ok, the way it works in PHP 7. But the speed of access to const

Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

S.A.N wrote: > > const CONST_ARRAY = > [ > 'key' => 'value' > ]; > > isset(CONST_ARRAY['key']); // Fatal error: Cannot use isset() on the > result of an expression (you can use "null !== expression" instead) > > ?> > > It is design, or a bug? It is by design; the documentation states[1]:

RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately -> thanks Oracle)

Hi, > > OK, this looks fine. Maybe we should involve Oracle people. > > Unfortunately, I have no direct contact regarding iPlanet. > > I have good contacts to the Oracle Quality Assurance team in Ireland, > > but that is regarding Java. But those people are not responsible to this > issue. > > > A

[PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6

'value' ]; isset(CONST_ARRAY['key']); // Fatal error: Cannot use isset() on the result of an expression (you can use "null !== expression" instead) ?> It is design, or a bug? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium

How should we reconcile your standard recommendations with NaCl proper and how libsodium is used in other languages? I'll try to loop Frank Denis in on this conversation again, but any specific objections (esp. bikeshedding) would probably be best moved towards new issues on the jedisct1/libsodium

Re: [PHP-DEV] libpcre 8.37 requires extra flags (at least on AIX)

Hi, It seems to be AIX only thing, as it builds fine for me for Linux/Darwin. Any hints ? Kaplan On Wed, May 20, 2015 at 9:28 PM, Stanislav Malyshev wrote: > Hi! > > > While building the PHP 5.6.9 (which has libpcre 8.37) it seems we're > > missing -lpthreads build flag (for cli SAPI), as thi

Re: [PHP-DEV] [RFC] JSON number to string

> 24 мая 2015 г., в 19:02, Jakub Zelenka написал(а): > > Hi, > > I would like to introduce my and Pasindu's RFC that proposes adding of new > JSON options for converting number values to string when decoding and/or > encoding: > > https://wiki.php.net/rfc/json_numeric_as_string > > Personally