Arnaud Limbourg [2006-07-10 08:47 UTC] It sounds reasonable. New packages will most likely be PHP5 so setting E_STRICT as a requirement makes sense.
Lukas Smith [2006-07-10 09:09 UTC] I also think it is time we nudge people a bit more strongly towards PHP5. Even if PHP5 is not the standard at this point, we need to realize that its also in our hands to change the tides.
I would however leave some option open for PHP4 packages. Maybe simply increase the required +1 total to be higher than for PHP5 packages (say : 10 or 15).
Also I think we should simply mandate that packages always adhere to the highest error reporting level for the lowest supported PHP major version. That should become a CS guideline.
Pierre-Alain Joye [2006-07-10 09:52 UTC] I agree by also leaving the option to propose PHP4 packages too. Sometimes it makes sense to have a php4 package. There is still areas to be filled for php4. I'm not saying to keep the status quo but to still allow php4 packages when it is required.
"Also I think we should simply mandate that packages always adhere to the highest error reporting level for the lowest supported PHP major version. That should become a CS guideline."
I agree here.
Alan Knowles [2006-07-10 10:16 UTC] It may be worth double checking the version of PHP5 to target, E_STRICT has changed quite a bit since it was first introduced.. -> and from what I remember some 5.1 versions may still be broken as far as E_STRICT goes..
Justin Patrin [2006-07-10 14:45 UTC] I'm a bit worried about this:
"it has only E_STRICT-compatible required dependencies"
While I understand that technically you can't run in E_STRICT mode with a non-E_STRICT file/package included the code in any package can be E_STRICT compliant without this requirement. Requiring package to only have E_STRICT dependencies means that we, collectively, have to start over from scratch for any dependencies we may need and/or convert existing packages to E_STRICT, causing a new major version with no real gain.
Philippe Jausions [2006-07-10 16:59 UTC] I don't really see the point of this RFC. Packages make their way into PEAR because people wrote them and wanted to share them with the rest of the world. Sometimes these packages *had* to be written in PHP4. And some other users may need such a version as well.
I understand the need to move forward to PHP5, but if people can't use a PHP5 version of a package and a PHP4 is available, the RFC shouldn't forbid the PH4 package to make it into PEAR.
The RFC should state that new packages must provide a PHP5 E_STRICT version, but not restrict to that version only.
The dependency on E_STRICT packages will slow development if nothing is done first to up some major existing packages.
In the (recent) past when a PHP5 package was submitted, a PHP4 version was asked if the said package was not really using PHP5-only features. I guess these kind of backward compatibility requests should be discouraged.
Joshua Eichorn [2006-07-10 19:24 UTC] What does E_Strict entail as of 5.1.4
I've looked in the PHP manual but I can't seem to find a definition of what it actually means. With var being allowed it doesn't seem like it takes much to get too E_Strict
Lukas Smith [2006-07-10 19:33 UTC] The main thing is properly marking methods that are to be called as static. Other than that it affects contructor naming. Some things are mentioned here:
http://derickrethans.nl/pres-breaking/
I dont know if it raises any notices when using deprecated functions yet.
Stefan Neufeind [2006-07-12 22:45 UTC] I agree that being as "strict as possible" makes sense and proves for good style. But on the other hand I don't see why packages not taking advantage of any PHP5-only-features should not be using allowed anymore.
That saying I clearly do support "that packages always adhere to the highest error reporting level for the lowest supported PHP major version. That should become a CS guideline."
If the general consent is encouraging developers to use special PHP5-features where possible, I support that idea. But I'm still for individually deciding if it makes sense or not - e.g. as Pierre said it might make sense to accept a good php4/5-package in some cases. Maybe Lucas' suggestion helps here - raising the "barrier to entry" for php4-compatible packages a bit higher (I think 10 are fine).
Joshua Eichorn [2006-08-03 17:11 UTC] I would like to see a guideline of what changes this entails. E_STRICT is a undocumented feature which makes this requirement a pain to fullfill.
Daniel Convissor [2006-08-10 12:38 UTC] Regarding instanceof, can the wording be changed from "should be used instead of" to "is preferred to"? This is mainly because of autoload situations, let alone is_a() has been un-deprecated.
Regarding E_STRICT dependencies, it seems best if encourage them rather force them. Perhaps we should leave room for the collective to decide whether the package is too important and/or the dependencies too vast.
We might want to wait on finalizing this RFC because PHP is close to making some decisions regarding what E_STRICT is.
|
