On Jun 17, 2016 1:10 PM, "Dmitry Stogov" wrote:
>
> Got it :(
> Then this may be a serious BC break, and it's better to depricate it in
7.1 and throw exception only in 8.
Fully agree. Thanks :)
> Thanks. Dmitry.
>
>
>
> On Thu, Jun 16, 2016 at 8:14 PM +0300, "Stanislav Malyshev" <
smalys...@gmai
Got it :(
Then this may be a serious BC break, and it's better to depricate it in 7.1 and
throw exception only in 8.
Thanks. Dmitry.
On Thu, Jun 16, 2016 at 8:14 PM +0300, "Stanislav Malyshev"
mailto:smalys...@gmail.com>> wrote:
Hi!
> Please review: https://wiki.php.net/rfc/constant_redefin
Hi Leigh,
I need to change stance wrt MT.
On 6/16/16, 2:31 PM, "Leigh" wrote:
>I get your point, but most people probably use mt_rand() because "it's
>better than rand". mt_rand is also incredibly slow and has a huge state
>when compared to modern algorithms. I should probably note the
>perfor
On Wed, Jun 15, 2016 at 11:25 PM, Dmitry Stogov wrote:
> Hi Pierre,
>
>
> On 06/16/2016 09:18 AM, Pierre Joye wrote:
>
>>
>> Hi Dmitry
>>
>> I am sorry but I have to ask to wait before merging it.
>>
>>
> Sorry, but this is already merged.
>
>>
>> It is definitely not clear that:
>>
>> . The rfc
On 16/06/2016 19:11, Levi Morrison wrote:
On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins wrote:
>
>Why? What's special about 7.1? If it was a case of finishing off changes
>that "should have been part of 7.0", I can see some kind of logic, but the
>ones we're actually discussing seem to be mo
On Jun 17, 2016 1:55 AM, "Fleshgrinder" wrote:
>
> On 6/16/2016 8:14 PM, Pierre Joye wrote:
> > Well know you do as I gave you examples of such usages. Their Code not
> > public so I cannot give you links.
> >
>
> That's a knockout argument.
>
> On 6/16/2016 8:14 PM, Pierre Joye wrote:
> > I am no
On 6/16/2016 9:13 PM, Stanislav Malyshev wrote:
> Hi!
>
>> it into 7.0 is plain wrong and only creates problems. Everyone is always
>> so concerned about breaking something if someone proposes some
>> deprecation but in such cases nobody cares.
>
> Because it's not about how it's proposed, but is
Hi!
> it into 7.0 is plain wrong and only creates problems. Everyone is always
> so concerned about breaking something if someone proposes some
> deprecation but in such cases nobody cares.
Because it's not about how it's proposed, but is about what impact it
will have on users. If you try to dep
On 6/15/2016 1:01 PM, Christoph Becker wrote:
> I don't know, but I can image that it is (test suites come to mind). Of
> course, it might be an option to move the functionality to PECL, but on
> the other hand, what would we gain? For users, however, that might be a
> major pain; consider softwa
On 6/16/2016 8:14 PM, Pierre Joye wrote:
> Well know you do as I gave you examples of such usages. Their Code not
> public so I cannot give you links.
>
That's a knockout argument.
On 6/16/2016 8:14 PM, Pierre Joye wrote:
> I am not sure to follow the legitimate part. There are perfectly legitim
RFC updated to include:
* A note about mt_rand()s poor performance
* Separate votes for proposals so we can at least get the security fixes
through
* Updated vote from 50% to 2/3 as it does cause a BC issue.
I should also state that mt_rand is easily implementable in userland, so
the correct/legac
On Wed, 15 Jun 2016 at 14:05 Jordi Boggiano wrote:
> Just a thought here, if the goal is to provide a better interface,
> wouldn't it be better to use OO for this? Not because OO is better, but
> because it would avoid having problems if two mt_rand-using pieces of
> code are executed concurrentl
On Wed, 15 Jun 2016 at 00:08 Tom Worster wrote:
> On 6/14/16 12:46 PM, Leigh wrote:
>
> > The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> Hi Leigh,
>
> Thanks for putting this together. I am strongly pro on two points and
> moderately contra on the other two. I'd prefer separate
On Jun 17, 2016 12:43 AM, "Fleshgrinder" wrote:
>
> On 6/16/2016 4:21 AM, Pierre Joye wrote:
> > No they don't all do it.
> >
>
> We don't know but I will try to find legitimate usages of (mt_)rand.
Well know you do as I gave you examples of such usages. Their Code not
public so I cannot give you
> I didn't necessarily mean the currently proposed; I mean more
> generally. For instance Nullable Types and the associated
> ReflectionType changes both have small BC breaks that I don't mind. In
> the case of the former there is a long-standing bug that did have BC
> break impact that was fixed.
On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins wrote:
> On 16/06/2016 17:24, Levi Morrison wrote:
>>>
>>> I also have to say that to the very short timeline to finalize 7.0
>>> should not be paid by breaking BCs in 7.x. We can have a short
>>> timeline for 8.0 as well. If we need more drastic BC
On 6/16/2016 4:21 AM, Pierre Joye wrote:
> No they don't all do it.
>
We don't know but I will try to find legitimate usages of (mt_)rand.
On 6/16/2016 4:21 AM, Pierre Joye wrote:
> There are ways to achieve what you want in a nice way while not breaking
> things. Let consider them.
>
Moving t
On 6/16/2016 6:30 PM, Rowan Collins wrote:
> On 16/06/2016 17:24, Levi Morrison wrote:
>>> I also have to say that to the very short timeline to finalize 7.0
>>> should not be paid by breaking BCs in 7.x. We can have a short
>>> timeline for 8.0 as well. If we need more drastic BC breaks earlier
>>
Hi!
> Please review: https://wiki.php.net/rfc/constant_redefinition
I would propose to not throw an error if constant is redefined to
exactly the same value. Some of the code might be doing this
unknowingly, e.g. by writing include instead of include_once, and
there's no real reason to break it.
On 16/06/2016 17:24, Levi Morrison wrote:
I also have to say that to the very short timeline to finalize 7.0
should not be paid by breaking BCs in 7.x. We can have a short
timeline for 8.0 as well. If we need more drastic BC breaks earlier
than expected. If JIT is a goal for 8.0, then let do the
> I also have to say that to the very short timeline to finalize 7.0
> should not be paid by breaking BCs in 7.x. We can have a short
> timeline for 8.0 as well. If we need more drastic BC breaks earlier
> than expected. If JIT is a goal for 8.0, then let do the BC breaks in
> 8.0 and prepare our u
Results for project PHP master, build date 2016-06-16 06:29:42+03:00
commit: fba6f90
previous commit:3389c2e
revision date: 2016-06-15 22:52:48+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
2016-06-15 22:28 GMT+03:00 Niklas Keller :
> didn't read it was planned for all file functions.
Let's restrict my first suggestion only for "require" expression for now.
So proposal is following:
Rewrite "require" to throw an Error instead of current Fatal Error if some
file can not be loaded.
Hi Joe,
On 16/06/2016 05:40, Joe Watkins wrote:
> Please don't let's make it harder to go from 7.0 to 7.1 than it was
from 5.6 to 7.0.
Can we reduce hyperbole to nil, please.
Sorry, yes, that was a bit hyperbolic on my part. I do think there is
the risk of making 7.0 to 7.1 as awkward
On 16/06/16 07:44, Dmitry Stogov wrote:
> RFC also proposes a way to "fix" affected applications, wrapping constant
> definitions, that may be redefined, with try/catch.
Doesn't anybody remember the problems which STILL have to be resolved
with changes in PHP5.2/3/4 which require the assistance o
On 15/06/16 03:51, Scott Arciszewski wrote:
> While we're at it, can we also add a function to generate (ephemeral)
> Elliptic Curve Diffie-Hellman keys, and then use openssl_dh_compute_key()
> with ECDH keys? Because that would be a lot saner than having to
> shell_exec() to the OpenSSL binary in
On Jun 11, 2016 4:27 AM, "Dmitry Stogov" wrote:
>
> In general, you are right, but this is possible only if application
ignores Error exceptions...
Exactly.
Many if not hundred of applications do not even use exception but if a
couple of places, let alone plug-ins for these apps.
Most of these
27 matches
Mail list logo
