Hi everybody!
I've noticed that the "Reserve Even More Types in PHP 7" RFC[1] has been
moved to "Process and Policy" with the comment "needs no impl".
However, the RFC states:
| This RFC does not fully reserve them as keywords; it only prohibits
| their usage as class, interface and trait names.
In my opinion, this has to be enforced by throwing a fatal error
("Cannot use '*' as class name as it is reserved"), whenever one of the
reserved identifiers (resource, object, mixed, numeric) is used as
class, interface or trait name.
Relying on documentation only seems to be insufficient to me. Consider
a developer not reading the documentation and facing the issue that
his/her code might break with PHP 7.1 (i.e. a minor version).
The "Backward Incompatible Changes" section appears to support my opinion.
[1] https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
--
Christoph M. Becker
Hi everybody!
I've noticed that the "Reserve Even More Types in PHP 7" RFC[1] has been
moved to "Process and Policy" with the comment "needs no impl".
However, the RFC states:| This RFC does not fully reserve them as keywords; it only prohibits
| their usage as class, interface and trait names.In my opinion, this has to be enforced by throwing a fatal error
("Cannot use '*' as class name as it is reserved"), whenever one of the
reserved identifiers (resource, object, mixed, numeric) is used as
class, interface or trait name.Relying on documentation only seems to be insufficient to me. Consider
a developer not reading the documentation and facing the issue that
his/her code might break with PHP 7.1 (i.e. a minor version).
+1
If not a fatal, it should be at least a warning. Doc-only keyword
reservation
won't be noticed.
On Thu, Apr 30, 2015 at 12:41 AM, Christoph Becker cmbecker69@gmx.de
wrote:
Hi everybody!
I've noticed that the "Reserve Even More Types in PHP 7" RFC1 has been
moved to "Process and Policy" with the comment "needs no impl".
However, the RFC states:| This RFC does not fully reserve them as keywords; it only prohibits
| their usage as class, interface and trait names.In my opinion, this has to be enforced by throwing a fatal error
("Cannot use '*' as class name as it is reserved"), whenever one of the
reserved identifiers (resource, object, mixed, numeric) is used as
class, interface or trait name.Relying on documentation only seems to be insufficient to me. Consider
a developer not reading the documentation and facing the issue that
his/her code might break with PHP 7.1 (i.e. a minor version).The "Backward Incompatible Changes" section appears to support my opinion.
I've moved the RFC based on Sara's mail in the voting thread 1. Quoting:
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.
I also know that at least some of the votes were cast under the assumption
that this is just a "documentation" reservation, as opposed to throwing
errors.
/cc Sara
Nikita
Nikita Popov wrote:
On Thu, Apr 30, 2015 at 12:41 AM, Christoph Becker cmbecker69@gmx.de
wrote:I've noticed that the "Reserve Even More Types in PHP 7" RFC1 has been
moved to "Process and Policy" with the comment "needs no impl".I've moved the RFC based on Sara's mail in the voting thread 1. Quoting:
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.I also know that at least some of the votes were cast under the assumption
that this is just a "documentation" reservation, as opposed to throwing
errors.
Thanks for the explanation. I must have missed (or simply forgotten
about) this mail. The voters have probably more carefully followed the
discussion, so enforcing the reservation by convention has been part of
the decision.
--
Christoph M. Becker
De : Christoph Becker [mailto:cmbecker69@gmx.de]
Relying on documentation only seems to be insufficient to me. Consider
a developer not reading the documentation and facing the issue that
his/her code might break with PHP 7.1 (i.e. a minor version).
+1. I already asked if we should enforce reserved names by a message and most replied that documentation was enough. This is the lazy (I could say 'political') option and can only lead to bad surprises when we decide to use the names. At this time, saying "People should have read the doc" won't help them in any way, especially if their code dates back from before 7.0, when this doc didn't exist yet.
We don't need a warning there, we need a fatal error. These names are invalid as class names.
Regards
François
Hi,
Le 30 avr. 2015 11:04, "François Laupretre" francois@php.net a écrit :
De : Christoph Becker [mailto:cmbecker69@gmx.de]
Relying on documentation only seems to be insufficient to me. Consider
a developer not reading the documentation and facing the issue that
his/her code might break with PHP 7.1 (i.e. a minor version).+1. I already asked if we should enforce reserved names by a message and
most replied that documentation was enough. This is the lazy (I could say
'political') option and can only lead to bad surprises when we decide to
use the names. At this time, saying "People should have read the doc" won't
help them in any way, especially if their code dates back from before 7.0,
when this doc didn't exist yet.We don't need a warning there, we need a fatal error. These names are
invalid as class names.
Should we throw fatal errors for functions starting with 2 underscores too?
Regards
François
--
Cheers,
Florian Margaine
De : Florian Margaine [mailto:florian@margaine.com]
Should we throw fatal errors for functions starting with 2 underscores too?
Well, you're right. Functions and methods, even if more people now know that these names are reserved.
Regards
François
Florian Margaine wrote on 30/04/2015 10:23:
We don't need a warning there, we need a fatal error. These names are
invalid as class names.
Should we throw fatal errors for functions starting with 2
underscores too?
Actually, soft reservation has genuine advantages for those:
-
It allows forwards compatibility - you can add an __debugInfo()
method to a project which supports PHP 5.5, even though it will never be
used until PHP 5.6. Since we have no conditional compilation, there's no
other way of enabling the feature only if it's available. -
It can be used to implement userland compatibility shims. For
instance, a framework's enhanced dump function could manually call
__debugInfo() on versions <5.6, or an event handling framework could
accept objects with an __invoke() method as callbacks on PHP 5.2.
I can think of no such advantage with reserved keywords for basic types,
since there is no way to use them in current code which would be
compatible with their future use.
Regards,
Rowan Collins
[IMSoP]