> I don't think we need a core function that almost exactly duplicates the > working of existing function but with a slight tweak. I do not think it is a good idea to do such things, it only produces more confusion.
I strongly disagree. The old function is actively causing confusion - the reported type-names aren't even inconsistent with scalar type-hints, and then you have to go and read the manual with some explanation about historical reasons why the function doesn't work like you'd expect. PHP is infamous for these surprise moments. I think that gettype() should be deprecated in favor of a new function that actually makes sense. I think that deprecating and fixing things is long-term less confusing than documenting your way around legacy functions that produce surprising and confusing results. IMO this is a clear improvement which *removes* a source of confusion. On Sat, Jun 4, 2016 at 10:38 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > > >> My number one issue with this PR is that it's all PHP code. There's > nothing > > in here that couldn't be done as a composer installable library > > > > It's a valid point, but not really a good argument against having it - > the > > same could after all be said about a lot of PHP functions. > > Many of those were introduced when we didn't have good ecosystem for > libraries, and whatever is baked into PHP binary is all you got to work > with. Not the case anymore. Many others were introduced because it was > hard to do it in PHP (no access to some internals, or slow, or required > things that code break between versions). Not the case here either. > > Also, there's a difference between core having 20 functions and adding > 21st that is doing something new, and core having 200 functions and > adding 201st that does exactly like one of the existing ones but > slightly different (slightly enough so you'd have to consult the manual > now to see why you used each of them in each context). > > -- > Stas Malyshev > smalys...@gmail.com >
