Hi Tom,
On Sun, Jan 22, 2017 at 1:26 AM, Tom Worster wrote:
> On 1/20/17 9:55 PM, Yasuo Ohgaki wrote:
>
>> CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't
>> fail with healthy hardware/OS.
>>
>
> One would like to think so but low entropy environments exist. The problem
>
Hi Leigh,
On Sun, Jan 22, 2017 at 6:40 PM, Leigh wrote:
> On Sat, 21 Jan 2017 at 14:41 Niklas Keller wrote:
>
>> Anyway, the "issue" with mt_rand is not the seed being predictable but
>> the internal state being recoverable from the output. But mt_rand is
>> predictable by design, so why shoul
On 1/25/2017 3:52 AM, Michael Wallner wrote:
Hi, I've updated the bug: https://bugs.php.net/bug.php?id=73493
TL;DR
The c-client lib performs a lot of caching; use imap_gc() to clean those
caches from time to time.
Ok, great. Will give that a try.
--
PHP Internals - PHP Runtime Development M
On 26/01/2017 20:23, Rasmus Schultz wrote:
Either way, guys, here's a preliminary RFC:
https://wiki.php.net/rfc/use-static-function
Just to pick up on one thing you mention on there, declaring static
classes. This has been discussed before, and an RFC went to a vote a
couple of years ago and
On 26/01/2017 21:37, Walter Parker wrote:
Why are functions useless when using Composer? Is it because functions
can't be autoloaded?
Is this about getting functions to load without having to stick them in
classes that can be autoloaded?
Yes, and yes. The subject line of this thread is an allus
On Thu, Jan 26, 2017 at 12:23 PM, Rasmus Schultz wrote:
> > if you choose to use static methods instead of functions
>
> It's not a choice - functions are practically useless in a Composer
> context, and most everything PHP is now Composer packages.
>
> Why are functions useless when using Compos
On Thu, Jan 26, 2017 at 1:56 PM, Rasmus Schultz wrote:
> Besides, I mean, I'm sure this has occurred to everyone, right?
>
> https://gist.github.com/mindplay-dk/4ef61fd5c0a35e5aa8fc699febb86487
>
> I personally find that this new syntax you're proposing requires a lot of
> parsing.
>
> I mean, whe
Besides, I mean, I'm sure this has occurred to everyone, right?
https://gist.github.com/mindplay-dk/4ef61fd5c0a35e5aa8fc699febb86487
I personally find that this new syntax you're proposing requires a lot of
parsing.
I mean, whenever you see substr() or array_map() etc. you're intuitively
expecti
> if you choose to use static methods instead of functions
It's not a choice - functions are practically useless in a Composer
context, and most everything PHP is now Composer packages.
> why do you need this special syntax for calling them then?
Yeah, but the same logic applies to namespaces an
Hi!
> BUT, it would great to fix the inability of __toString to throw in 7.2 also.
That might be a bit harder to do. __toString does not throw because it's
used in many contexts inside the engine where you can't just drop what
you're doing and start processing the exception - like in the middle o
>
> > The problem with stop-gap measures is they become entrenched, and the
> proper solution doesn't get implemented
>
> This would be my general point of view - unfortunately, functions are
> essentially useless at present, in a world with Composer, unless you're
> willing to preload all function
Results for project PHP master, build date 2017-01-25 20:28:51-08:00
commit: b8f1c79
previous commit:e7166d1
revision date: 2017-01-25 20:59:52+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
> The problem with stop-gap measures is they become entrenched, and the
proper solution doesn't get implemented
This would be my general point of view - unfortunately, functions are
essentially useless at present, in a world with Composer, unless you're
willing to preload all functions from all pa
On Thu, Jan 26, 2017 at 10:46 AM, Niklas Keller wrote:
> >
> > Since the autoloading functions proposal is stalled, how about allowing
> for
> > import of static functions instead?
> >
> > use function Foo::bar;
> >
> > bar(); // calls Foo::bar()
> >
> > There are two benefits to this app
>
> Since the autoloading functions proposal is stalled, how about allowing for
> import of static functions instead?
>
> use function Foo::bar;
>
> bar(); // calls Foo::bar()
>
> There are two benefits to this approach:
>
> 1. There is immediate support for autoloading without any need for
Hi,
Rasmus Schultz wrote:
Since the autoloading functions proposal is stalled, how about allowing for
import of static functions instead?
The problem with stop-gap measures is they become entrenched, and the
proper solution doesn't get implemented. But we may be at the risk of
the latter any
16 matches
Mail list logo
