Hi Sammy,
On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers wrote:
> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:
>
> https://github.com/php/php-src/pull/1397 (main discussion)
> https://github.com/php/php-src/pull/1398
>
> Currently the random_*() functions will iss
On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
> Hi Sammy,
>
> On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers wrote:
>
>> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:
>>
>> https://github.com/php/php-src/pull/1397 (main discussion)
>> https://github.com/php/p
Sammy Kaye Powers wrote on 14/07/2015 22:04:
Since the core functions in PHP don't throw Exceptions, there is debate on
whether or not this change should be implemented. Some say the CSPRNG's
should get a special pass since they will be relied on for cryptography. If
we can't throw Exceptions, th
Hi Scott,
On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski
wrote:
> On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
> > Hi Sammy,
> >
> > On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers wrote:
> >
> >> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:
> >>
> >>
Hi Rowan,
On Wed, Jul 15, 2015 at 7:57 PM, Rowan Collins
wrote:
> Sammy Kaye Powers wrote on 14/07/2015 22:04:
>
>> Since the core functions in PHP don't throw Exceptions, there is debate on
>> whether or not this change should be implemented. Some say the CSPRNG's
>> should get a special pass s
On Wed, Jul 15, 2015 at 6:57 AM, Yasuo Ohgaki wrote:
> Hi Scott,
>
> On Wed, Jul 15, 2015 at 7:19 PM, Scott Arciszewski
> wrote:
>>
>> On Wed, Jul 15, 2015 at 4:27 AM, Yasuo Ohgaki wrote:
>> > Hi Sammy,
>> >
>> > On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers wrote:
>> >
>> >> There are two
Hi!
A few weeks ago I resurrected a two year old proposal for adding two array
functions, namely array_every() and array_some(), modelled after their
JavaScript equivalent.
https://github.com/php/php-src/pull/1385
The most notable comment was that it would be nice to support Traversable
as well
try {
random_*();
} catch (SomeException $e) {
// Something
}
... is far cleaner than telling developers to override the error
handler for one specific function.
That said, I won't oppose E_RECOVERABLE_ERROR or E_ERROR if that's
what the rest of the Internals team settles on. Just don't e
On 15/07/15 13:28, Tjerk Meesters wrote:
> Hi!
>
> A few weeks ago I resurrected a two year old proposal for adding two array
> functions, namely array_every() and array_some(), modelled after their
> JavaScript equivalent.
>
> https://github.com/php/php-src/pull/1385
>
> ...
>
> Let me know wh
Hi all,
Session module's E_ERROR could be E_RECOVERABLE_ERROR.
http://lxr.php.net/search?q=E_ERROR&defs=&refs=&path=ext%2Fsession&hist=&project=PHP_TRUNK
Any comments changing the error?
--
Yasuo Ohgaki
yohg...@ohgaki.net
Yasuo Ohgaki wrote on 15/07/2015 12:20:
Engine exception is a little different. The main motivation for engine
exception is
to give a chance to users for graceful program termination. Functions
can achieve
the objective by E_RECOVERABLE_ERROR mostly.
This is simply incorrect, as demonstrated
Hi,
On Wed, 2015-07-15 at 11:28 +, Tjerk Meesters wrote:
> The most notable comment was that it would be nice to support Traversable
> as well as arrays; instead of only supporting this for my own functions,
> I've generalised this so that other functions can take advantage of this as
> well.
On Wed, Jul 15, 2015 at 3:43 PM, Johannes Schlüter
wrote:
> Hi,
>
> On Wed, 2015-07-15 at 11:28 +, Tjerk Meesters wrote:
> > The most notable comment was that it would be nice to support Traversable
> > as well as arrays; instead of only supporting this for my own functions,
> > I've generali
On Wed, Jul 15, 2015 at 8:31 AM, Julien Pauli wrote:
> On Wed, Jul 15, 2015 at 3:43 PM, Johannes Schlüter
> wrote:
>
>> Hi,
>>
>> On Wed, 2015-07-15 at 11:28 +, Tjerk Meesters wrote:
>> > The most notable comment was that it would be nice to support Traversable
>> > as well as arrays; instead
On 15 July 2015 20:39:05 GMT+01:00, Levi Morrison wrote:
>Do note that the union types RFC would also alleviate some of this
>pain for user-land functions, since `array | Traversable` would cover
>the required access pattern. I think this is a superior approach
>myself, but I may be a bit biased a
On Wed, Jul 15, 2015 at 9:53 PM, Rowan Collins
wrote:
> On 15 July 2015 20:39:05 GMT+01:00, Levi Morrison wrote:
> >Do note that the union types RFC would also alleviate some of this
> >pain for user-land functions, since `array | Traversable` would cover
> >the required access pattern. I think
Hi Rowan,
On Wed, Jul 15, 2015 at 9:00 PM, Rowan Collins
wrote:
> If we are going to adopt exception for "functions", it would be better to
>> have
>> switch that convert all errors to exceptions.
>>
>
> Strongly disagree. A runtime switch would be a horrible consistency
> nightmare for userland
On Thu, Jul 16, 2015 at 4:58 AM, Yasuo Ohgaki wrote:
> I understand many of us dislike INI switch nor runtime switch that changes
> behavior. However, it's impossible to move to exception at once because we
> have no control for users' code including 3rd party modules.
Well, ini settiing remains
We are looking at reordering the PDO statement-free dtors to fix a
resource leak in PDO_OCI. Let me know if this will affect other
drivers.
Chris
*** pdo_stmt.c.orig 2015-07-15 09:56:18.986187123 -0700
--- pdo_stmt.c 2015-07-15 09:57:22.292453715 -0700
***
*** 2300,2305
19 matches
Mail list logo
