Re: Two suggested changes to the interop spec

Why not allow discretion with (b) as well? Perhaps something along the lines of "if the package or library can operate independently, it should define its own exception within its own namespace," so things like database layers, form libraries, etc. etc. that can operate independently do have that ability, without requiring it of all packages that are expected and designed to be used as a cohesive unit. At the same time, not requiring, but suggesting that these independent libraries throw namespaces exceptions, allows developers to opt out of the throwing error model, which might be desirable in some situations. So, in conclusion, regarding exceptions: "If a package can be used independently of other vendor-specific packages AND throws exceptions as a means of error handling, it must throw a namespaced exception defined as such: vendor\package\[subpackage\[subpackage\]]Exception. However, if the package does not throw exceptions, this is not required. If a group of packages are intended to work as a cohesive unit (a group of packages that together form a forum, for example), it is suggested that they throw vendor-specific exceptions that are namespaced at the highest level of hierarchy they share." On Tue, Jun 30, 2009 at 12:05 PM, David Zülke<david.zuelke@bitextender.com> wrote: > Hi folks, > > a) I think we should use "SHOULD", not "MUST", for the > "Interface" and > "Abstract" suffixes. The simple reason is that they are not required for the > standard autoloader; it'll work no matter what the class name is. I've seen > lots of complaints about "Interface", "Abstract" or both of them, and I > guess it doesn't hurt to give folks some freedom there. > > b) we should require that the standard Exception interface or implementation > be put in the namespace that is the reasonable choice for the situation in > question. For instance, ZF might have an exception per package, but if a > small project owns a vendor namespace (e.g. PHPCouch) with just a couple > sub-packages that are not usable independently of one another, it'd be > nonsense to require base exceptions from all these subpackages, as they'd be > pretty much meaningless. Maybe we could define a "project level" that can be > either the vendor level, or the package level, depending on the intention of > the library in question. > > Cheers, > > - David