On 6/26/2016 12:31 PM, Dan Ackroyd wrote: > Hi Richard, > Hi Dan!
On 6/26/2016 12:31 PM, Dan Ackroyd wrote:
> As other noted elsewhere by others, the name of the function is
> slightly misleading for this case:
>
> var_type(1 + 1);
>
> However I don't have a better suggestion.
>
The name comes from Sara from the original typeof() discussion thread. I
understand the arguments of the people but as I already explained on
Reddit, the usage of var_type() on expressions like the above is nothing
anyone would ever do, especially if the TYPE_INT constant is exposed in
userland. One would only use it to get the type of the value that is
currently stored in a variable of which the type is unknown.
vat_type() or value_type() could be good choices as function name.
However, both would introduce new prefixes and I actually do not think
that this is a good idea because it will require people to remember more
and more and more prefixes which makes no sense. It is a declared goal
of this RFC to make is simpler for developers to find what the need
(aided by their IDE and brain). Remembering that you can get additional
information about a variable (its value, type, ...) via the super old
var_* prefix is definitely a good thing, shows visions, and an overall
goal. Note that I plan to provide a var_info() function in my next RFC
that builds upon this.
TL;DR I still like Sara's suggestion and intend to keep it.
On 6/26/2016 12:31 PM, Dan Ackroyd wrote:
> From the second half of the RFC:
>
>> const TYPE_FALSE = 'false';
>> const TYPE_TRUE = 'true';
>
> Although as an implementation detail they are present in the engine,
> those aren't types in userland. i.e. you can't do
>
> function foo(true $i_only_accept_true) {}
>
Yes, I also struggled to actually expose them (and write a comment for
them). I searched some code bases and found many usages of literal true
and false, this convinced me that there is a need for them. Introduction
of true and false as type declarations was also discussed and proposed
multiple times (did not make as of yet though).
I am definitely open to removing them again! Should we add a third poll?
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
