var_type #1935
var_type #1935
Conversation
Magic strings are bad in any programming context, repeating the same string over and over again too even if everyone knows what they mean. It increases the chance of typos and requires string searches throughout the whole code base to find usages. Usage of constants helps to mitigate this problem and keeps changes localized.
Additionally sorted everything alphabetically, helps to identify the right line very fast.
|
Wouldn't it have been more interesting if this was a language construct instead, we might even be able to perform some compile time optimizations. e.g.: $language = 'PHP'; Given we already reserve the type keywords, this should not be a problem. |
|
This was discussed on the mailing list and will be answered in the RFC, short answer no. The reason is simple, we do not want to have yet another operator and rather extend the functionality of the existing |
|
I agree that extending the functionality of instanceof is a better idea, $var instanceof string sounds good to me. |
| case IS_TRUE: | ||
| RETURN_VAR_TYPE(ZEND_STR_BOOL); | ||
|
|
||
| /* case IS_FLOAT: */ |
There was a problem hiding this comment.
Has this been left in for documentation purposes? Or is this a case that should be added back in?
There was a problem hiding this comment.
Right now only documentation purpose but hopefully in the future it becomes the actual case. See future scope of the RFC.
It is true that both literal string values `true` and `false` are sometimes required in userland software in the context of type related functionalities. However, the should not be provided through the `TYPE_*` constants simply because it would introduce too much inconsistency since they are not types in userland PHP.
It was simply a stupid mistake and I deleted the `TYPE_FLOAT` constant instead of the `TYPE_FALSE` constant.
|
Closing here as the RFC has been declined. |
Proposal for a
gettype()successor, originates from and closes #1932 in favor of this PR.