Re: PEAR-wide code quality issue (fix proposal for possible class redeclare errors)

Well Alan, as I have seen in the explanations, such things happen e.g. if you include (=require) files using logically different paths to the same file. If this happens in code from different vendors, whose error is that? Also class naming conflicts are a source of this error. I had a situation where I had to combine two application subsystems which were from the application design point view absolutely compatible (XOOPS and Propel). Because of the absense of classname prefixes in both projects there was a conflict on the name "Criteria". (oh PHP gods allow us to have namespaces!!! :-) ) Actually two groups of programmers had produced that error, not me :=) Of course catching/preventing the fatal error wouldn't bring much in this cas, but: in general in VERY large systems where huge amounts of classes are loaded dynamically it could be helpful to avoid this fatal error, maybe loading some other default class with less functionality which implements the same interface. I agree that catching a fatal error might allow bad programming techniques but as you see another bad programming technique is already possible (PHP does not really care if you include the same file but from different or even "different" e.g. wich are physically the same paths). Dynamically created fatal error is not always nice for your customers if this situation slips through your testing model. with best regards, Peter Fiksman, B.Sc. in Computer Science ----- Original Message ----- From: "Alan Knowles" <alan@akbkhome.com> To: "peter fiksman" <pfiksman@gmx.net> Cc: <pear-dev@lists.php.net> Sent: Wednesday, July 26, 2006 3:00 AM Subject: Re: [PEAR-DEV] PEAR-wide code quality issue (fix proposal for possible class redeclare errors) > In my view, the current behaviour is correct, It's a programmer error! - > not an application error. - > The message is 'you've made a mistake - fix it!' > it's a bit like throwing an exception on a syntax error... - I know > PHP's a bit loose there, but, allowing serious programming errors to be > caught is a little ridiculous... > > I've not seen one case where this is not a programmer mistake, but I'm > alway open to being enlightened.. > > Regards > Alan > > peter fiksman wrote: > > Yes, an Exception is catchable so you can produce some better error than > > "fatal error". > > > > Furthermore, if Exception is carried along with the class def all that > > class_exists checks are not needed: the class definiton itself throws the > > Exception if loaded twice. > > > > Maybe it should even be the default PHP behaviour since PHP5 :) > > > > > > > >> ----- Original Message ----- > >> From: "Lukas Smith" <lsmith@php.net> > >> To: "Matthew Weier O'Phinney" <mweierophinney@gmail.com> > >> Cc: <pear-dev@lists.php.net> > >> Sent: Tuesday, July 25, 2006 8:42 AM > >> Subject: Re: [PEAR-DEV] PEAR-wide code quality issue (fix proposal for > >> possible class redeclare errors) > >> > >> > >> > >>> Matthew Weier O'Phinney wrote: > >>> > >>>> On 7/23/06, peter fiksman <pfiksman@gmx.net> wrote: > >>>> > >>>>> Hello, still one question more on this topic: > >>>>> > >>>>> why not throw an exception then, like: > >>>>> > >>>>> if (!class_exists(Class_Name)) > >>>>> { > >>>>> class Class_Name > >>>>> > >>>>> { > >>>>> // class def goes here > >>>>> } > >>>>> > >>>>> } > >>>>> else > >>>>> { > >>>>> > >>>>> throw new Exception ("fatal error caught, redefining classname ... in > >>>>> ".__FILE__); > >>>>> > >>>>> } > >>>>> > >>>> Because PHP already does this by throwing a fatal error. Why reinvent > >>>> the wheel? > >>>> > >>> Well he seems to want an Exception, which is catchable. However instead > >>> of writing code to catch he should just do a class_exists() check before > >>> doing the require. > >>> > >>> regards, > >>> Lukas > >>> > >>> -- > >>> PEAR Development Mailing List (http://pear.php.net/) > >>> To unsubscribe, visit: > >>> http://www.php.net/unsub.php > >>> > >>> > > > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >