This may not have been the best way to put it. The point I was trying to make was that while BC Breaks do occur, they are very easy to solve.
The impact on downstream projects will be significant, and there may be many extensions affected, since this change concerns a frequently used RNG feature. However, in other words, it may need to be sorted out as soon as possible. However, I also understand the theory that this should be done in conjunction with a major language change. Perhaps I should have suggested this for PHP 8.0. Either way, I'll try to separate these suggestions if necessary, but if we were to try to provide an OOP API without BC Break, what do you think would be the ideal form? Regards, Go Kudo 2021年9月5日(日) 4:24 Dan Ackroyd <dan...@basereality.com>: > On Fri, 3 Sept 2021 at 18:41, Go Kudo <zeriyo...@gmail.com> wrote: > > > > Nikita wrote: > >> this one also moves all of the existing RNG-related functionality > >> from ext/standard to ext/random. > > > > There are several reasons for this. > > > > - The `random` extension name is already used by ext/standard and may > > interfere with the build system. > > - Due to the namespace rules for new extensions, it is inappropriate to > > rename an extension. > > - Due to history, the rand / mt_rand dependency is tricky and I thought > it > > was time to sort it out. > > - I don't think it's a good idea to have multiple header files for a > single > > domain feature. > > Have you considered how much work that is going to incur on downstream > projects? > > If there's a good reason for moving stuff around then it can be > appropriate, but the RFC phrasing of: "At the same time, the > following internal APIs will also be relocated. If you want to use > them, you can _simply_ include ext/random/random.h." sounds pretty > dismissive of causing possibly unneeded work for downstream projects. > > cheers > Dan > Ack >
