The voting period for the "Even More" type hints reservation RFC is now open.
Reminder, any types reserved via this RFC are dependent on at least
one of the STH RFCs passing, or Levi's base types reservation RFCs
passing as it's silly without at least one of those.
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
Vote will close on the later of 2015-03-29 or the close of all
currently open STH RFCs and Levi's base type reservation RFC.
-Sara
The voting period for the "Even More" type hints reservation RFC is now open.
Hi Sara,
There's been a little bit of traffic on the list in the past few days;
I don't think your RFC has received enough cogent discussion.
In particular the keywords 'Resource' and 'mixed' seem to have limited
need to be reserved. I don't believe there has been any suggestion
that either of these would actually be used as types for PHP 7.x. So
making them be unusable seems to be a large BC hit for no gain for
people who currently have classes that use them
It's possible that people are voting yes to reserve these two words,
without fully considering whether they should be reserved or not. I
can see that all of 'object', 'scalar', and 'numeric' have been
proposed as part of future improvements to PHP's type system.
Can anyone please make a strong argument for why 'resource' and
'mixed' should be reserved, if we currently have no plans to use them?
cheers
Dan
The voting period for the "Even More" type hints reservation RFC is now open.
There's been a little bit of traffic on the list in the past few days;
I don't think your RFC has received enough cogent discussion.
I can't force people to talk about something. Especially something so
minor while the war-of-the-century is being waged.
In particular the keywords 'Resource' and 'mixed' seem to have limited
need to be reserved. I don't believe there has been any suggestion
that either of these would actually be used as types for PHP 7.x. So
making them be unusable seems to be a large BC hit for no gain for
people who currently have classes that use them
To be clear, this RFC is about declaring these names as reserved, not
about actually /using/ them. There's no language in the RFC about
actually throwing errors or other code-breaking behavior. Therefore,
even should all of them pass, it does NOT mean that your code using
these names suddenly stops working on PHP7. It means that you have
been warned that using the names of intrinsics is a bad idea, and that
the language reserves the /right/ to make doing so an error at some
point in the future.
Can anyone please make a strong argument for why 'resource' and
'mixed' should be reserved, if we currently have no plans to use them?
In the case of "resource", because it refers to a real type in PHP's
type system. Using that intrinsic as an arbitrary label is a bad
idea. It'd be like putting your project's code in the PHP namespace.
There's nothing in the language preventing you from doing so, but it's
a bad idea. Formalizing that it's a bad idea is what this RFC does.
As far as "mixed"... I don't have a strong reason for it. TBQH, I'm
not strongly in favor of all of these supplemental types. but they're
included for completeness, and presented as individual voting options
for flexibility.
-Sara
In particular the keywords 'Resource' and 'mixed' seem to have limited
need to be reserved. I don't believe there has been any suggestion
that either of these would actually be used as types for PHP 7.x. So
making them be unusable seems to be a large BC hit for no gain for
people who currently have classes that use them
I agree, mixed seems to serve no purpose (just don't hint the parameter,
same result). Resource is something we're hopefully going to phase out over
time as they get replaced with objects (like Nikita already did with GMP,
and hopefully will happen to streams some time between now and 7.1 :)).
It's possible that people are voting yes to reserve these two words,
without fully considering whether they should be reserved or not. I
can see that all of 'object', 'scalar', and 'numeric' have been
proposed as part of future improvements to PHP's type system.
I don't really like scalar or numeric (but I'm in the strict types camp and
I think if union types ever make it in, they should be user definable).
Object makes sense to me though, apart from resource it's the only one that
represents a single underlying type.
I agree, mixed seems to serve no purpose (just don't hint the parameter,
same result). Resource is something we're hopefully going to phase out over
time as they get replaced with objects (like Nikita already did with GMP,
and hopefully will happen to streams some time between now and 7.1 :)).
It has been pointed out to me, that mixed is useful for being explicit,
rather than having a single untyped parameter amongst typed ones, you know
that it was designed to accept anything rather than being an oversight.
Completely valid point.
rather than having a single untyped parameter amongst typed ones
Yes, when experimenting with strict types, I'd rather move things in and
out of 'mixed' than remove the notation completely. Like you said, 'mixed'
means, "I've reviewed this area and concluded it needs to be dynamic."
Also, maybe I missed this upthread, but are the docs still going to refer
to 'mixed'?
-- Sandy
rather than having a single untyped parameter amongst typed ones
Yes, when experimenting with strict types, I'd rather move things in and
out of 'mixed' than remove the notation completely. Like you said, 'mixed'
means, "I've reviewed this area and concluded it needs to be dynamic."Also, maybe I missed this upthread, but are the docs still going to refer
to 'mixed'?
Yes.
-- Sandy
Le 16/03/2015 07:44, Sara Golemon a écrit :
The voting period for the "Even More" type hints reservation RFC is now open.
Hi,
Discussing this RFC with other people at AFUP, we are +1, for all five
proposed types (well, even if not really "types" today).
Like for the "reserve more types" RFC, this will cause a few BC-breaks
here and there, but they should not be too hard to fix; and it opens
doors for the future.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
This vote was supposed to end on 29/3 but it seems to still be open.
Can someone with proper access finish it?
Rafael Dohms wrote:
This vote was supposed to end on 29/3 but it seems to still be open.
Can someone with proper access finish it?
To my knowledge, everyone with a VCS account could do this.
--
Christoph M. Becker
This vote was supposed to end on 29/3 but it seems to still be open.
Can someone with proper access finish it?
To my knowledge, everyone with a VCS account could do this.
Sorry, I got really busy with other things and completely forgot about
this. I'll close it up now.