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.