Re: [PHP-DEV] Re: Improving mt_rand() seed <lauri.ken...@gmail.com>

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

Re: [PHP-DEV] Not autoloading functions

2017-01-28 21:37 GMT+01:00 Wes : > I suppose that is because they use just few functions. I don't think you > would want to have 20-30 functions in the same file :P > I wouldn't call these just a few functions: - https://github.com/nikic/iter/blob/master/src/iter.php -

Re: [PHP-DEV] Not autoloading functions

I suppose that is because they use just few functions. I don't think you would want to have 20-30 functions in the same file :P

Re: [PHP-DEV] Not autoloading functions

> > I'm sorry, it's unacceptable for who? Only for not defined function it > would be called. If I call the same function a thousand times, the autoload > will be attempted just the first time, and if it doesn't work then the > script would die, exactly like classes. Any project I know that uses >

Re: [PHP-DEV] Not autoloading functions

> > old applications could maintain compatibility only > > by adding a simple autoloader that would alias the global > function/constant > > into the calling namespace > > So as a side-effect of calling any function, my namespace would get > polluted with all sorts of random names? That sounds

RE: [PHP-DEV] Fwd: Type Collection

Niklas, there are several relevant points that you raised up, thanks :) Q - «How is the active usage and how are frameworks related to making it not an object but something entirely new instead? » A - Before Php starting to slightly evolves from a procedural way (the begins of wordpress,

Re: [PHP-DEV] Fwd: Type Collection

2017-01-28 17:49 GMT+01:00 Georges.L : > Hello Niklas, > > > > This something very pertinent that you noticed. Thanks you for pointing it > out. > > > > Q - “sounds like everything you want is typed arrays” > > A- It’s much more than simple typed arrays. I forgot to mention

RE: [PHP-DEV] Fwd: Type Collection

Hello Niklas, This something very pertinent that you noticed. Thanks you for pointing it out. Q - “sounds like everything you want is typed arrays” A- It’s much more than simple typed arrays. I forgot to mention that those “Collection” would be passed, like objects, by reference. Meaning

Re: [PHP-DEV] Fwd: Type Collection

2017-01-28 16:37 GMT+01:00 georges : > Hello > ​ ​ > Php Internals, > > I was wondering today why did we not have (yet ?)​ > ​ ​ > a Collection type in Php ? > Typically what would be that kind of variable type ? > > This type would be a great intermediate between an array and

[PHP-DEV] Fwd: Type Collection

Hello ​ ​ Php Internals, I was wondering today why did we not have (yet ?)​ ​ ​ a Collection type in Php ? Typically what would be that kind of variable type ? This type would be a great intermediate between an array and an Object. Today, in my opinion we are seeing to much wrong uses of php

Re: [PHP-DEV] Not autoloading functions

> old applications could maintain compatibility only > by adding a simple autoloader that would alias the global function/constant > into the calling namespace So as a side-effect of calling any function, my namespace would get polluted with all sorts of random names? That sounds like a messy

Re: [PHP-DEV] Allow "static" type

I completely agree with what you said. Static inheritance is wrong. Static members shouldn't be inherited. This is what I think and probably what you think too. But it's too late to fix this. I don't think it's worth changing the expectations of the users, which rely on inherited members to be

Re: [PHP-DEV] Allow "static" type

On 28 January 2017 at 10:18, Wes wrote: > Hi​, static could be definitely a valid return type, but I don't see this > happening for parameters, for the same reasons this is disallowed: > > class A{ function bar(A $a){} } > class B extends A{ function bar(B $b){} } // must be

Re: [PHP-DEV] Allow "static" type

Hi​, static could be definitely a valid return type, but I don't see this happening for parameters, for the same reasons this is disallowed: class A{ function bar(A $a){} } class B extends A{ function bar(B $b){} } // must be contravariant, but B is covariant to A However again, it works as