On Mon, Jan 16, 2017 at 4:04 PM, Yasuo Ohgaki wrote:
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
>
> ext/standard/php_rand.h
Hi all,
Since I was about to improve uniqid()'s entropy by replacing
php_combined_lcg() to php_random_int(), I spent time to check other places
that could be a problem.
mt_rand()'s is seeded as follows by default.
ext/standard/php_rand.h
#ifdef PHP_WIN32
#define GENERATE_SEED() (((zend_long) (ti
Morning internals,
Could I ask anyone with some spare time to review the open pull requests
labelled Awaiting Review:
https://github.com/php/php-src/pulls?q=is%3Apr+is%3Aopen+label%3A%22Awaiting+Review%22
Please create a new comment with at least a thumbs up if the patch is
acceptable.
The PDO
Hi all,
On Mon, Jan 16, 2017 at 10:47 AM, Yasuo Ohgaki wrote:
>
> Comments are appreciated.
> If there is no comment, I'll work on these improvements hopefully soon.
>
Forgot to mention one more thing.
I also would like to make HKDF a PHPAPI.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi!
> For short the thing is: "We have objects that do dynamic loading and
> there might be recursions. We could use recursion depth to decide
> when we want to do dynamic loading and when not.
>
This looks like a hack covering for deficient design. Having objects
that look differently depending
Hi all,
On Wed, Jan 11, 2017 at 11:24 PM, Andrey Andreev wrote:
> Hi all,
>
> There's a pending GitHub pull request of mine to include a HKDF
> implementation into ext/hash.
> Mostly anybody who saw it agreed that it probably doesn't require an RFC
> vote, but I hadn't originally announced it he
I do that too... but I feel bad for doing it :P Property accessors would be
great to have...
Almost forgot: these examples apply also to private and protected
properties. That's currently the only way to make the behavior consistent
across friend objects (same scope).
On Mon, Jan 16, 2017 at 12:27 AM, Marco Pivetta wrote:
> Hi Wes,
>
> This has been discussed before, and it's currently
Hi Wes,
This has been discussed before, and it's currently used to intercept access
to properties. Since we don't have property accessors (sigh), the code
(simplified version) would look like following:
class Foo
{
public $bar = 'baz';
}
class FooInterceptor extends Foo
{
private $wrappe
Hello elephpants.
Currently PHP allows explicitly declared fields (eg public $foo = 10;) to
be removed entirely through unset (eg unset($obj->foo)).
Now that isn't really an issue as properties in php are currently untyped
and therefore nullable; at worst you would get a notice. But it would
beco
On Wed, Jan 11, 2017 at 8:06 AM, Jani Ollikainen
wrote:
> Hi,
>
> I've made a pull request where I was asked to start internal discussion
> about it.. The pull request can be found:
> https://github.com/php/php-src/pull/1884
> Which relates to request I've also made:
> https://bugs.php.net/bug.p
We discussed this whole thing in different channels and together refined
the original idea as well as what the actual problem and a solution
would be.
The actual problem are multiple calls to the constructor because they
break the encapsulation. We know that there are many ways to do so but
this i
On 14/01/2017 14:58, Giovanni Giacobbi wrote:
If you go for blocking explicit calls to __construct() (i'm personally in
favour of it), i hope you would change the syntax for its only legitimate
use which is calling the parent's constructor within a constructor, so how
about something like parent(
Hi internals,
I've started the vote on https://wiki.php.net/rfc/deprecations_php_7_2. All
votes are 2/3 majority and end on 29-01-2017.
Thanks,
Nikita
On 15.01.2017 at 11:53, Pierre Joye wrote:
> Just got a bunch of emails and see that one. I agree about object for
> anims. Make the APIs also more friendly.
>
> I will post a detailed reply by Wednesday
Thanks!
Cheers,
Christoph
> Thanks for your work!
> Pierre
>
> On Jan 9, 2017 7:53 AM, "C
2017-01-15 12:41 GMT+01:00 Giovanni Giacobbi :
> You are right, I feel responsible for it (but proudly), as an excuse please
> consider that the three topics covered have a certain dependancy:
>
> Forbid __construct calls -> Forbid in constructor as well for coherency ->
> need a new way to call p
You are right, I feel responsible for it (but proudly), as an excuse please
consider that the three topics covered have a certain dependancy:
Forbid __construct calls -> Forbid in constructor as well for coherency ->
need a new way to call parent's constructor
(bonus topic: implicit constructors)
17 matches
Mail list logo
