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

peter fiksman wrote: > > 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? I'd suggest to file a bug with these vendors, as the PEAR way is to NOT use fullpath to include PEAR packages in application. Since PEAR packages are libraries of code, they cannot make any assumption of how they will be used. > 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!!! > :-) ) I understand that integrating 2 or more applications can be troublesome, as they sometimes come with their own delivery of PEAR packaging, and referr to that path instead of a global PEAR installation. As you pointed out, there is no namespace in PHP, and even if there was, it would guarantee that the vendors would actually use them, so you'd be back to square 1. The problem is really an application problem. The vendor should write good code enough that it would not have to change the way PEAR packages should be included... That is, they should register the path to (their) PEAR intallation in "include_path" Anything that is not PEAR related, is of course out-of-topic here.. > 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 -Philippe