[RFC DISCUSSION] var_type

php.internals

Fleshgrinder

10 years ago
I changed my initial proposal for typeof() to var_type() and would like to start the discussion on it: https://github.com/php/php-src/pull/1935 The functionality is straight forward.
-- Richard "Fleshgrinder" Fussenegger

Fleshgrinder

10 years ago
I finished the RFC: https://wiki.php.net/rfc/var_type
-- Richard "Fleshgrinder" Fussenegger

Theodore Brown

10 years ago
On Sat, 25 Jun 2016 17:25 +0200 Fleshgrinder wrote: > > I finished the RFC: > > https://wiki.php.net/rfc/var_type > Thanks for this RFC! I think it's a great way to make PHP's type system more consistent without breaking backwards compatibility. I especially like that it would fix confusing error messages like "Argument must be an instance of boolean, boolean given." I noticed that the "A Successor" section of the RFC still contains a bunch of references to typeof (in the function signature and code examples). Did you forget to change these to var_type? Theodore Brown

Fleshgrinder

10 years ago
On 6/25/2016 7:57 PM, Theodore Brown wrote:
> Thanks for this RFC! I think it's a great way to make PHP's > type system more consistent without breaking backwards > compatibility. I especially like that it would fix confusing > error messages like "Argument must be an instance of boolean, > boolean given." >
Glad you like it. :) Updating confusing error messages and other type related things will be the next step that I take. This RFC and its function is just the beginning. On 6/25/2016 7:57 PM, Theodore Brown wrote:
> I noticed that the "A Successor" section of the RFC still contains > a bunch of references to typeof (in the function signature and code > examples). Did you forget to change these to var_type? >
Indeed I overlooked them, thanks for the heads up will fix it right away (in other words, when the wiki is back online).
-- Richard "Fleshgrinder" Fussenegger

Dan Ackroyd

10 years ago
Hi Richard, On 25 June 2016 at 16:25, Fleshgrinder <php@fleshgrinder.com> wrote:
> I finished the RFC: > > https://wiki.php.net/rfc/var_type >
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. 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) {} cheers Dan

Fleshgrinder

10 years ago
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