On 6/5/2016 3:21 PM, Zeev Suraski wrote: > 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. >
You are completely ignoring the fact that the deprecation and removal of gettype() is actually part of my proposal. Anyone who continues to use gettype() should be informed that this is not the idiomatic way of performing this action and to use the new function instead. It might be a /slight inconsistency/ but it is at the same time a very shameful and sad one. Our language is not able to tell us the type of a variable! On 6/5/2016 3:21 PM, Zeev Suraski wrote: > 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. > That is true, yes. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
