> -----Original Message----- > From: Rasmus Schultz [mailto:ras...@mindplay.dk] > Sent: Sunday, June 05, 2016 2:51 PM > To: Stanislav Malyshev <smalys...@gmail.com> > Cc: Sara Golemon <poll...@php.net>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeof > > > So let's add more of it by having multiple functions that do exactly > > the same > thing but name null and float differently. > > It's a point of view, that's all. > > You can choose your point of view - I choose the point of view where we > replace a broken function with a function that does what developers would > actually *expect*. > > You know what, all this rhetoric in favor of inconsistency, against a solution > that has already been implemented?
We're weighing a certain level of inconsistency that exists with gettype(), with a different kind of inconsistency - having typeof() and gettype() both be members of the language, and behave subtly inconsistently with each other. So this is not consistency vs. non-consistency, we're choosing between two non-ideal options. IMHO, we're better off sticking with the devil everyone knows; The inconsistency is there but it's not a very strong one with few practical issues. IMHO, we're better off having this compared to having two similar-but-different options. People for whom gettype() is inadequate can obtain typeof() (or whatever it will be called) using Composer. For people for whom this is a non-issue (vast majority I would believe), don't have to be confused by two similar-but-different options. As a side note, the fact we happen to have an implementation for this should play no role in whether we accept a proposal like this or not; This holds true for most RFCs - unless the implementation manages to achieve some remarkably complex feat, and even then - it should stand at its own merit. Zeev
