Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Hi Rowan and Larry, > Isn't that exactly what a deprecation period is for? > Yes, sure, but I wrote my arguments with the "Short deprecation period" in mind so that the removal of these functions causes the least pain. > If we want to give people longer, just leave the functionality deprecated > for longer before removing it. If we want to phase that in gradually, start > with a documentation-only deprecation, and add the deprecation notice > later. > If the plan is to keep the current function name, we can't get any of the > (very small) benefits of removing the extra signature until the final > removal anyway. > I don't completely understand this sentence, but my current plan is to go with the original function name as this causes the least impact and at the same time makes the scope of the RFC smaller. I'm tired of the debates (even if they were useful), and I don't want to add any tangentially related things in the RFC anymore. Anyway, adding an alias (session_set_handler()) and/or deprecating the original function name later is trivial, if someone wants to pursue this. > I'd propose a doc-only deprecation now (with session_set_handler() added > for the object version), an E_DEPRECATED in 9.0, and full removal in 10.0. Assuming the expected > release schedule, that gives people ~2 years before they see even an E_DEPRECATED, and 6-7 > years before they are forced to change. That should be ample time for anyone that still needs > to make the switch. I want to keep the original voting choices (the short and long path). Then votes can decide how much notice period they want to give. Since I don't insist on changing the function name anymore, the impact of this change is a lower, as only people using the callback signature would be affected. The fortunate thing is that session handling is used less in library code so at least open source maintainers rarely have to deal with the deprecation. And proprietary code maintainers can mostly ignore or suppress it for a while. Regards, Máté
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Wed, Jun 21, 2023, at 11:57 AM, Rowan Tommins wrote: > On Wed, 21 Jun 2023 at 09:43, Máté Kocsis wrote: > >> The reason why I think it's a good approach to have an intermediate state >> is to give >> these people the possibility to defer the actual migration until the >> very end. >> > > > Isn't that exactly what a deprecation period is for? > > If we want to give people longer, just leave the functionality deprecated > for longer before removing it. If we want to phase that in gradually, start > with a documentation-only deprecation, and add the deprecation notice later. > > If the plan is to keep the current function name, we can't get any of the > (very small) benefits of removing the extra signature until the final > removal anyway. > > Regards, > -- > Rowan Tommins > [IMSoP] I'm inclined to agree here, I think. I am all for a very-long grace period to give people lots of time for this change, but if the end state is just the object version being supported, then adding functions in the mean time doesn't make sense to me. I'd propose a doc-only deprecation now (with session_set_handler() added for the object version), an E_DEPRECATED in 9.0, and full removal in 10.0. Assuming the expected release schedule, that gives people ~2 years before they see even an E_DEPRECATED, and 6-7 years before they are forced to change. That should be ample time for anyone that still needs to make the switch. (A generic "functions to object wrapper" class is probably a not-too-hard composer package for someone to write, either, but that's not a task for internals.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Wed, 21 Jun 2023 at 09:43, Máté Kocsis wrote: > The reason why I think it's a good approach to have an intermediate state > is to give > these people the possibility to defer the actual migration until the > very end. > Isn't that exactly what a deprecation period is for? If we want to give people longer, just leave the functionality deprecated for longer before removing it. If we want to phase that in gradually, start with a documentation-only deprecation, and add the deprecation notice later. If the plan is to keep the current function name, we can't get any of the (very small) benefits of removing the extra signature until the final removal anyway. Regards, -- Rowan Tommins [IMSoP]
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Hi Bruce, For those who use callbacks now, how is this in any way better? They will > eventually end up using an OOP approach anyway (as that's the strategic > goal). > Migrating from `session_set_handler_callbacks()` would still be > (potentially) > non-trivial. And what's the point migrating *to* > `session_set_handler_callbacks()` > if we already know it will be deprecated and removed soon enough? The reason why I think it's a good approach to have an intermediate state is to give these people the possibility to defer the actual migration until the very end. So they can choose what to do when the 6+ parameter version of session_set_save_handler() becomes deprecated: they can either go straight to session_set_handler() *if they are ready* or they can also choose gaining time with a very straightforward change and use session_set_handler_callbacks() for at least a couple of years more. The important thing is that people are not yet forced to make a bigger effort, unless they are already ready for that. Regards, Máté
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Wed, Jun 21, 2023 at 12:54 AM Máté Kocsis wrote: > * In order to finally achieve the strategic goal, we deprecate the old > function along with session_set_handler_callbacks() > as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z, > whatever. For those who use callbacks now, how is this in any way better? They will eventually end up using an OOP approach anyway (as that's the strategic goal). Migrating from `session_set_handler_callbacks()` would still be (potentially) non-trivial. And what's the point migrating *to* `session_set_handler_callbacks()` if we already know it will be deprecated and removed soon enough? -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
HI Nicolas and Rowan, Mate, WDYT of 2)? Your sentence about better typing rang a bell with me: I think that's the best argument for removing the signature accepting callables. But before coming to a conclusion, let me answer Rowan's question first: This is where I don't understand what you or Maté consider to be the > alternative. If we create any function with a new name, then we have two > names for the user to choose between, regardless of whether that's one old > name and one new, or two new names. That's why I'm saying that if we have > two names at all, they should both be chosen with new users in mind, not > fudged based on a combination of current and new naming styles. > > Once the deprecation period is over, we should be left with a pair of names > that obviously signals the difference; or, we should be left with only one > function. > Of course, the best situation would be to have only the new function name with a single signature. Personally, I also prefer the OO style, but this doesn't really matter now. However, the sad truth is that we have a very widespread function with a slightly incorrect name supporting 2 signatures for more than a decade... On top of that, while most of the other deprecations in the RFC either affect rare functionality, or are suppressable via a simple polyfill or some automation/search+replace, only supporting the OO style signature of session_set_save_handler() would mean that people would have to wrap the callbacks in a class. This is not automatable, and requires some possibly non-trivial manual work. This means that we have to change anything really carefully here. With all these in mind, I'd say that the strategic goal should be to have a single signature + the new function name only. Reaching this state would affect every single proprietary codebase in some way or another, so I don't think it's feasible or fair with users to try it in one single step. So in order to reduce the damage, my plan is the following: * Let's keep one of the two signatures which are compatible with older PHP versions so that at least a fraction of all users (maybe 50-70%?) are not impacted at all. That's why session_set_save_handler() should not be removed just yet. Since the OO version seems more future-proof based on Nicolas' great argument (it accepts an interface, while callbacks don't have a formal signature), we should keep this form. * People who use the signature to be deprecated should not be forced to do non-trivial changes. So introducing a new function for them will keep their code run with a minimal effort (search + replace), while we managed to eliminate the overloaded signature. At the same time, we try to educate them (mostly in the manual) that the best way forward is to migrate their code to use session_set_handler(). There's no deprecation just yet, and everyone can do it voluntarily at their own pace. * In order to finally achieve the strategic goal, we deprecate the old function along with session_set_handler_callbacks() as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z, whatever. This process may sound complicated, but in my opinion, this is the least disruptive upgrade path for achieving the goal I outlined above. Sometimes going full ninja mode is possible, but I'd prefer being careful in this very case, especially because I guess some people do not consider the motivation of the RFC particularly important, so I would like if their cost-benefit analysis would stay positive (I don't only mean voters but end users as well, since their perception also matters when they are fixing the incompatibilities of their code). Máté
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Tue, 20 Jun 2023 at 09:22, Nicolas Grekas wrote: > > So are you saying we should deprecate the function-based version > > completely, and not provide any new names at all? I think I would prefer > > that to the confusing set of aliases the current RFC text proposes. > > > > I was not but I would be fine with this solution also :) > Then I don't understand the reasoning of picking a "best" - is the "best" one the one that keeps the old name, which is unclear but requires no changes; or is the "best" one the one that gets a clearer name, and immediately has a non-overloaded signature that everyone can use? > > 1) Do nothing. I don't see the current situation as being that big a > > problem. > > > > The problem is the overloaded signature, which Mate explained in the RFC. > Sure; I just don't see any of the things mentioned as big enough problems to justify significant disruption to users. > THIS would create confusion to me, because ppl would have > two names to choose from, and many won't take the time to figure out the > difference. > This is where I don't understand what you or Maté consider to be the alternative. If we create any function with a new name, then we have two names for the user to choose between, regardless of whether that's one old name and one new, or two new names. That's why I'm saying that if we have two names at all, they should both be chosen with new users in mind, not fudged based on a combination of current and new naming styles. Once the deprecation period is over, we should be left with a pair of names that obviously signals the difference; or, we should be left with only one function. Regards, -- Rowan Tommins [IMSoP]
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
> Then, among both options, we need to select the one with the best future > > proofness, and that's definitely the OOP one to me, because it comes with > > more guarantees (type checks). > > > So are you saying we should deprecate the function-based version > completely, and not provide any new names at all? I think I would prefer > that to the confusing set of aliases the current RFC text proposes. > I was not but I would be fine with this solution also :) > I think I would support any of these options: > > 1) Do nothing. I don't see the current situation as being that big a > problem. > The problem is the overloaded signature, which Mate explained in the RFC. > 2) Deprecate the function-based signature, provide no alternative but to > switch to the interface-based one. Potentially non-trivial upgrade for > those affected, but leaves us with a single clear function. > Would work for me! The OOP way can be implemented since more than 10 years. > 3) Create new names for both signatures, treating neither of them as > more "default" than the other, so that users have a clear choice between > the two. Deprecate the existing function completely. > Deprecating in the same version that provides the alternative would create a lot of friction (even if in this case, it's possible to polyfill, which makes this a bit less rough). So to me, this path requires providing an alias without deprecating the OOP version first, and later on deprecating the current name. THIS would create confusion to me, because ppl would have two names to choose from, and many won't take the time to figure out the difference. Mate, WDYT of 2)? Nicolas
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On 20/06/2023 07:26, Nicolas Grekas wrote: Then, among both options, we need to select the one with the best future proofness, and that's definitely the OOP one to me, because it comes with more guarantees (type checks). So are you saying we should deprecate the function-based version completely, and not provide any new names at all? I think I would prefer that to the confusing set of aliases the current RFC text proposes. I think I would support any of these options: 1) Do nothing. I don't see the current situation as being that big a problem. 2) Deprecate the function-based signature, provide no alternative but to switch to the interface-based one. Potentially non-trivial upgrade for those affected, but leaves us with a single clear function. 3) Create new names for both signatures, treating neither of them as more "default" than the other, so that users have a clear choice between the two. Deprecate the existing function completely. All the other suggestions seem likely to create a lot of confusion, and not actually leave us much better off in the long term. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Le lun. 19 juin 2023 à 22:33, Rowan Tommins a écrit : > On 19/06/2023 21:17, Nicolas Grekas wrote: > > I think we must account for a bit of history/legacy on the topic. > > I think session_set_save_handler(SessionHandlerInterface) is the best > BC/FC > > path we can provide. > > > Can you elaborate? The SessionHandlerInterface is the *newer* of the two > current signatures, so what does making it the preferred signature (with > users of the other having to change their code) have to do with > "history/legacy"? Sure : SessionHandlerInterface is around 5.4. It's been there since long enough to not care about this aspect when considering both signatures. In my experience, supporting 3 major versions is way enough: previous major, current major and next major. Which means 7+8+9 in this case. It's enough because an app that runs on < 5.4 doesn't need to prepare to move to 9. It first has many more steps to do. Then, among both options, we need to select the one with the best future proofness, and that's definitely the OOP one to me, because it comes with more guarantees (type checks). By doing so, we allow apps that are still on 7 but are also actively planning to upgrade to 8+ to make the future-proof choice of choosing SessionHandlerInterface. Nicolas
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On 19/06/2023 21:17, Nicolas Grekas wrote: I think we must account for a bit of history/legacy on the topic. I think session_set_save_handler(SessionHandlerInterface) is the best BC/FC path we can provide. Can you elaborate? The SessionHandlerInterface is the *newer* of the two current signatures, so what does making it the preferred signature (with users of the other having to change their code) have to do with "history/legacy"? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Le mer. 14 juin 2023 à 23:51, Máté Kocsis a écrit : > > > > Given that you've agreed that neither signature is "primary" or "better", > > doesn't that argument apply equally to both signatures? If it's OK to > force > > anyone using individual callbacks to change their code, why is it not > > equally OK to force anyone using an object to change their code? > > > > As far as I remember, my reasoning was two-fold: > - naming: passing *multiple* callbacks to a function name in singular > (session_set_save_handler()) > is definitely not ideal > - a decision had to be made and I thought that keeping the OO approach in > place had less BC impact, > especially because previously I got feedback from Nicolas that they used > this version. > > > > I do wonder if this change is too disruptive relative to the benefit it > > brings, but in that case, we should just leave the whole function as it > is. > > > > In my opinion, phasing out session_set_save_handler() completely would be > worth the effort if this > was the only option to fix the overridden signature. However, it's not the > case, since strictly speaking, > only one of the two signatures has to be removed in order to achieve the > desired goal of the RFC. > The whole discussion about also deprecating the other one started only > because of improving naming: > it is also a nice thing to pursue but fails the cost-benefit analysis. All > in all, I think neither not doing > anything, nor deprecating the whole function is a good choice. But at least > I definitely want the question > to be settled with putting this to vote. > > I don't think "handler" particularly implies "object". The "handler" passed > > to set_error_handler is a function, and your original suggestion for a > new > > function was "session_set_save_handlers", where "handler" would also mean > > "function". > > > > Without any suffix at all, it seems like "set a session handler the normal > > way" vs "set a session a special different way"; like how > > "array_merge_recursive" is a special version of "array_merge". > > > > I think my reasoning is easier to understand if we go back to my original > suggestion: > session_set_save_handler() and session_set_save_handlers(), which would be > session_set_handler() and session_set_handlers() now. That was the starting > point, > but you didn't like that they only differ by an "s". That's why I swapped > the "s" with "callbacks". > > According to your deduction, session_set_handler() is not the most correct > name indeed, but I don't think > that we always have to choose the most correct and the entirely descriptive > one. After all, neither the > parameters of session_set_handler() are called "$open_callback", > "$close_callback" etc., they are just > "$open", "$close" etc. and I guess they are still clear enough, given that > their type is declared which > completes the missing context. > > Similarly, we all would know that the session_set_handler() function > expects an object of > SessionHandlerInterface type, while its sibling, > session_set_handler_callbacks() expects some > callbacks. Yes, having the _object suffix is the most pedantic name, but > personally, I don't really like it > because I find it ugly (and I was pretty much content with > session_set_handlers()). I'm curious about > the point of view of other people though, because if it turns out that > people generally also favor some > other name then I'm ok with a compromise. > I think we must account for a bit of history/legacy on the topic. I think session_set_save_handler(SessionHandlerInterface) is the best BC/FC path we can provide. And I don't think we should alias this function to a new name because that would require users to make a choice, and will lead to confusion, because in this case, the choice is purely cosmetic, but people will still have to get it. Nicolas
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On 14/06/2023 22:51, Máté Kocsis wrote: The whole discussion about also deprecating the other one started only because of improving naming: it is also a nice thing to pursue but fails the cost-benefit analysis. In my mind, making two new names, both unambiguous, gives a greater benefit (a clearer final state) without that much extra cost (more people will have to change their code, but fewer will be confused about whether they need to or not). All in all, I think neither not doing anything, nor deprecating the whole function is a good choice. The more I think about it, the more I'm leaning towards not doing anything being the best choice. The benefit seems small, and the cost high. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
> > Given that you've agreed that neither signature is "primary" or "better", > doesn't that argument apply equally to both signatures? If it's OK to force > anyone using individual callbacks to change their code, why is it not > equally OK to force anyone using an object to change their code? > As far as I remember, my reasoning was two-fold: - naming: passing *multiple* callbacks to a function name in singular (session_set_save_handler()) is definitely not ideal - a decision had to be made and I thought that keeping the OO approach in place had less BC impact, especially because previously I got feedback from Nicolas that they used this version. > I do wonder if this change is too disruptive relative to the benefit it > brings, but in that case, we should just leave the whole function as it is. > In my opinion, phasing out session_set_save_handler() completely would be worth the effort if this was the only option to fix the overridden signature. However, it's not the case, since strictly speaking, only one of the two signatures has to be removed in order to achieve the desired goal of the RFC. The whole discussion about also deprecating the other one started only because of improving naming: it is also a nice thing to pursue but fails the cost-benefit analysis. All in all, I think neither not doing anything, nor deprecating the whole function is a good choice. But at least I definitely want the question to be settled with putting this to vote. I don't think "handler" particularly implies "object". The "handler" passed > to set_error_handler is a function, and your original suggestion for a new > function was "session_set_save_handlers", where "handler" would also mean > "function". > Without any suffix at all, it seems like "set a session handler the normal > way" vs "set a session a special different way"; like how > "array_merge_recursive" is a special version of "array_merge". > I think my reasoning is easier to understand if we go back to my original suggestion: session_set_save_handler() and session_set_save_handlers(), which would be session_set_handler() and session_set_handlers() now. That was the starting point, but you didn't like that they only differ by an "s". That's why I swapped the "s" with "callbacks". According to your deduction, session_set_handler() is not the most correct name indeed, but I don't think that we always have to choose the most correct and the entirely descriptive one. After all, neither the parameters of session_set_handler() are called "$open_callback", "$close_callback" etc., they are just "$open", "$close" etc. and I guess they are still clear enough, given that their type is declared which completes the missing context. Similarly, we all would know that the session_set_handler() function expects an object of SessionHandlerInterface type, while its sibling, session_set_handler_callbacks() expects some callbacks. Yes, having the _object suffix is the most pedantic name, but personally, I don't really like it because I find it ugly (and I was pretty much content with session_set_handlers()). I'm curious about the point of view of other people though, because if it turns out that people generally also favor some other name then I'm ok with a compromise.
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Tue, 13 Jun 2023 at 15:49, Máté Kocsis wrote: > I understand that communication is much simpler with your suggested > approach, however, deprecating something which everyone surely uses partly > undermines the efforts we have made for ensuring as much backward > compatibility as reasonably possible. > Given that you've agreed that neither signature is "primary" or "better", doesn't that argument apply equally to both signatures? If it's OK to force anyone using individual callbacks to change their code, why is it not equally OK to force anyone using an object to change their code? I do wonder if this change is too disruptive relative to the benefit it brings, but in that case, we should just leave the whole function as it is. > In my opinion, the "_object" suffix is superfluous. There would be two > session_set_handler*() functions: the first one accepts a session handler > (instance) (session_set_handler()) and the second one accepts session > handler callbacks (session_set_handler_callbacks()). They are not primary > or secondary, I just don't like the "_object" suffix, and I couldn't come > up with a better alternative. > I don't think "handler" particularly implies "object". The "handler" passed to set_error_handler is a function, and your original suggestion for a new function was "session_set_save_handlers", where "handler" would also mean "function". My interpretation of the names is that both versions of the function "set a session handler", but they differ in what type of handler - one "sets a session handler using function callbacks", the other "sets a session handler using an object instance". Thus, the first is "session_set_handler_functions" or "session_set_handler_callbacks" or so, and the second is "session_set_handler_object" or "session_set_handler_instance" or so. Without any suffix at all, it seems like "set a session handler the normal way" vs "set a session a special different way"; like how "array_merge_recursive" is a special version of "array_merge". Regards, -- Rowan Tommins [IMSoP]
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
> > In my mind, the only reason to change anything about this function is that > we can't properly overload a function based on its argument types. There's > nothing particularly "primary" or "better" about either of the two > signatures, it's just hard to document and use named parameters while > they're both part of one function. > Yes, that's the case exactly. > My suggestion was very explicitly that everyone using sessions should have > to change their code, to a name that explicitly mentions the parameter type > in its name (because that's the difference between the two). As I said, I > think it's much simpler to communicate "this function is deprecated, choose > the appropriate from these two names", rather than "this function is > deprecated in one format, but not the other, and if you are using the > deprecated format, you can use this instead". > I understand that communication is much simpler with your suggested approach, however, deprecating something which everyone surely uses partly undermines the efforts we have made for ensuring as much backward compatibility as reasonably possible. That's why I'm not in favor of officially deprecating the object oriented version of session_set_save_handler() just yet. I think soft deprecating it for now results in a smoother upgrade path by letting people optionally use its alias first (session_set_handler()), and then we can start nagging them later on. Otherwise, I would question why we had to have such a long discussion focusing mainly on the BC aspects of the proposal. I also understand that polyfilling session_set_save_handler() would also be easy to do, but the migration is even easier if we leave the 2-parameter version alone for a while. Both the "_object" suffix (or some equivalent) and deprecating the original > regardless of signature are inherent in my suggestion. You seem to have > interpreted it as something else, and I'm not entirely sure what you're > actually proposing - how does an alias fit in to something that's about > splitting a function into two? > In my opinion, the "_object" suffix is superfluous. There would be two session_set_handler*() functions: the first one accepts a session handler (instance) (session_set_handler()) and the second one accepts session handler callbacks (session_set_handler_callbacks()). They are not primary or secondary, I just don't like the "_object" suffix, and I couldn't come up with a better alternative. Regards, Máté
Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On 10 June 2023 08:31:24 BST, "Máté Kocsis" wrote: >Hmm, that's also a very good idea, and I support this. However, I'm >hesitant to deprecate the 2 parameter version of session_set_save_handler() >just yet, >since doing so would mean that everyone using sessions has to use a new >function... Instead, I opted for aliasing it to the new >session_set_handler() function (I'm not fond >of the "_object" postfix, because I regard it unnecessary as it operates on >SessionHandlerInterface instances). And we could maybe deprecate >session_set_save_handler() >altogether in a few years. Hm, I think we're not quite on the same page here. In my mind, the only reason to change anything about this function is that we can't properly overload a function based on its argument types. There's nothing particularly "primary" or "better" about either of the two signatures, it's just hard to document and use named parameters while they're both part of one function. My suggestion was very explicitly that everyone using sessions should have to change their code, to a name that explicitly mentions the parameter type in its name (because that's the difference between the two). As I said, I think it's much simpler to communicate "this function is deprecated, choose the appropriate from these two names", rather than "this function is deprecated in one format, but not the other, and if you are using the deprecated format, you can use this instead". Both the "_object" suffix (or some equivalent) and deprecating the original regardless of signature are inherent in my suggestion. You seem to have interpreted it as something else, and I'm not entirely sure what you're actually proposing - how does an alias fit in to something that's about splitting a function into two? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
