> 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
