Large mega patches re: E_ALL notices (Re: [drupal-devel] I do not care about PHP 5

[Anguo]

On Saturday 15 October 2005 09:17 pm, Gerhard Killesreiter 
wrote:
> I have been submitting patches for fixing notices in the
> past and think that more patches like this should be
> comitted. Large mega patches are unlikely to make it,
> though, as experience has shown.


May you say more, please?
Have 'mega patches' been submitted before to solve all E_ALL 
notices???
If I understand well Drupal's development model, it all 
boils down to whether Dries wants the patch or not? He 
doesn't seem to be very active on this list, so I guess he 
doesn't read it.
Has he said anything specific for or against this E_ALL 
issue? There's absolutely no point for us to prepare a 
patch if he's already made his mind against committing it.

You may have seen on this list that I'm working on precisely 
this.
http://drupal.org/node/28540
And I plan to work on incorporating all similar issues and 
patches, like:
http://drupal.org/node/30930
http://drupal.org/node/30800


What you say about 'large mega patches' being unlikely to be 
committed surprises me, because I would have believed the 
opposite was true for the E_ALL issue.

Part of the patch reads like this:

 function error_handler($errno, $message, $filename, $line) 
{
-  if ($errno & (E_ALL ^ E_NOTICE)) {
+  if ($errno & (E_ALL )) {

This is the heart of the matter! but changing this line will 
suddenly affect all the code, because it is currently quite 
messy, and error notices will start to crop up everywhere, 
making more than one person unhappy. So the patch would 
need to be BIIIG so as to cover at the very least 90% of 
possible errors (one single page view of admin/settings 
printed no less than 1480 errors and maybe more than 1500 
on the screen... all dealt with by the patch I propose!!!)

The solution would be to NOT change that line, but then, 
other developpers will not see the error notices and would 
carry on with their bad coding practices while we try to 
keep up providing patches, hoping they get committed.
What's the point in creating disparate small patches while 
the codes changes rapidly and more mistakes (undeclared 
variables) are made than we get the opportunity to fix?

If you understand the dilemma above, you'll also understand 
why I thought a big patch would have had a better chance to 
be committed, and set a cut off point beyond which all 
developpers would have to adopt stricter coding practices.

Yet, I am very new in this community, and I do not know 
people and stuff...
Certainly you have experience that I do not have and you 
know things I don't. That's why I beg you to clarify your 
statement and advise me on the best course of action so 
that we can work from cleaner code (I had to clear some php 
that read, for example:
  $sql .= "SELECT blah....";
that would create an error notice about $sql not being 
set... I wonder why the dot in .= what put there in the 
first place...).


Please, kindly advise.
thanks.






-- 
http://www.wechange.org/
Because we and the world need to change.
 
http://www.reuniting.info/
Intimate Relationships, peace and harmony in the couple.

http://www.gnosis-usa.com/
Revolutionary Psychology, White Tantrism, Dream Yoga...

http://www.masquilier.org/
Condorcet, Approval alternative, better voting methods.