Hi, First of all I'd like to see this (clean) RFC formalized / ratified sooner rather than later.
Just to chime in here from a user / framework developer perspective in regards to *double* / *real* / *boolean* / *integer* reservation: i'd like to see these aliases (and the is_*-functions etc) be deprecated / removed sooner than later instead of kept around. It's minor, i know, but consistency wins above a quick find/replace above all. With lesser roads to the destination (rome), the easier the route to follow ;) Atleast have it on a roadmap somewhere instead of keeping it around and in every discussion with regards to reserved keywords, typehints, return types etc etc Thanks and keep up the good work ! (can't wait to see what PHP7.0 will actually bring to the table) Thnx, Robin Speekenbrink 2015-02-20 17:11 GMT+01:00 Andrey Andreev <n...@devilix.net>: > Hi, > > On Fri, Feb 20, 2015 at 6:00 PM, Levi Morrison <le...@php.net> wrote: >> On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev <n...@devilix.net> wrote: >>> >>> Agree on 'double' though ... if we want to discourage its usage, we >>> might even think of deprecating it. >> >> While deprecating it might be a good course of action, it is out of >> scope of this RFC. I personally think that reserving it is a good way >> to discourage its use: simply reserve it and then don't use it for >> anything. If we decide not to use the aliases if we have scalar types >> and the aliases are reserved this would prevent users from making >> custom types from the aliases. In my opinion this a Good Thing. > > Well, I meant to deprecate is_double(), is_real() and the > corresponding explicit casts. I might be missing other places when > they are used, not sure, but the point would be to stop using these > names for scalar types at all, so that everybody can freely use them > for class/trait/interface names ... I don't think anybody would do > that only for pseudo-scalar hinting objects. > > So, while yes - that's outside of this RFC's scope, reserving them as > keywords would be the opposite of what I had in mind. > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
