> On 18 בפבר׳ 2016, at 23:42, Stanislav Malyshev <smalys...@gmail.com> wrote: > > Hi! > >> I've created a bulk-deprecation RFC for PHP 7.1: >> https://wiki.php.net/rfc/deprecations_php_7_1 > > I like dropping php_errormsg. Last time I tried to make error > suppression work more efficiently this was a major problematic thing > AFAIR, and in general using magic variables that pop out of nowhere is > not a good thing.
I think we need to try and get an idea for the popularity of it before deprecating it, as well as get an idea for what kind of performance benefits it would bring (price/performance for making this change). > For __autoload I guess since it's incompatible with superior SPL > mechanism it has to go too. Agreed. > I'm not sure about create_function() - while it is old, I don't see why > we should break working code using it just because better option is > available. There's that, and there's the fact closures don't give you the same functionality - as Andrea pointed out. I think deprecating it and forcing people to rewrite their code differently (either with eval or with closures) doesn't make a whole lot of sense when create_function() works perfectly well. In terms of security risks, if you use it like you use closures I don't think it's any riskier. If you need eval() for programmatically creating functions - it would obviously be at the exact same risk levels. So we're left with marginal performance gains - as practically speaking you don't typically create thousands of functions dynamically in a given request. If you do, chances are you've already migrated to closures. > > With rand functions, I don't think we need to touch them. For some > applications, low-key randomness is just fine - if you need to shuffle > array of 20 elements or randomize unit test to ensure you're not testing > same value all the time, low-quality randomness is completely fine. For > other applications, there are superior solutions and everybody who needs > them already uses them, but again I see no value in removing those > functions. It would only cause more breakage and make adoption of new > versions (already horrible) even slower. I think the obvious option here is to make rand() and srand() aliases to rand_mt() and srand_mt(), unless I'm missing something very basic, unless I'm missing something very basic here..? I see zero reason to deprecate them and break so much code when we can simply 'upgrade' them at zero cost to both us and users. I think that this is something we should try to do in general, by the way. Deprecating is easy, upgrading is not - and we should strive to minimize code breaks as much as possible. If we can reimplement an old functionality in a new and better and seamlessly provide a painless upgrade experience we should always prefer it to forcing the users to edit their code. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
