Originally I had a lengthly reply...but I'll just address the following:
The Ninja Space Goat wrote:See that's what I figured... that it would be pretty damn convenient to have the ability to KNOW a method exists in all your objects.
Why not just check to make sure the object is of a certain, interface and if you want functionality, make it a abstract base class you check for???
The Ninja Space Goat wrote:Especially for things like unit testing. Although I can't think of exactly how I would use it for unit testing, it just seems like it might be a really cool way to provide "unit testing methods" although something about this smells to me... Is it bad practice to create methods that are only intended to be used for unit testing?
Yes. Bad practice.
1) Testing methods, should not exist in production code - especially in interpreted languages like PHP - it wastes resources.
2) Unit testing anything with inheritence becomes increasingly difficult or at least a greater PITA
I want to reply carefully, like stepping on eggshells - because everyone will have one of two opinions on this and neither are "right" or "wrong" it really depends on the circumstances.
Inheritence is bad, not in theory, but in use. I use inheritence frequently, but more often than not, I find myself refactoring entire class families into something more linear - especially after I understand the problem clearly.
Most of us learn inheritence first, then about composition, so it's natural we attempt to solve problems with each technique in that order. Both are valid solutions, but solve different problems better or worse than the other.
In PHP...the general rule of thumb I follow:
"If more than 3 classes need to derive from a super class - I should re-think my design"
I know this sounds crazy, because it's a detriment to very idea of code-reuse "a la" inheritence - but it's a rule of thumb that has served me well in keeping my designs flexible and extensible.
There are cetainlly reasons, some of those PHP frameworks use a super base class design...but I think it's more "old habits" rather than best interest of the project. When I first came to PHP from C++ I had a helluva time *not* wanting to throw everything into a base class...it's common in C++ and some Java Frameworks (J2EE). The thing is, under those environments and especially in Window'ing frameworks it often makes sense to have a super base class. The problems those base classes solve however, are already solved for PHP developers, either by the language itself or the environment.
- RTTI
- Object Serialization
So you don't really need a super base class in PHP general application frameworks.
Functionality like:
- Logging
- Profiling
- Language
- Debugging
- Class or module loading
I feel these are all better left to the discretion of the client developer, not the framework developer. Basically, let them determine what functionallity needs to be "plugged" into the code they are writing to accomplish the task at hand.
If I'm writing a CLI script - I likely don't need language functionality.
As for the others, I would rather use my own logging facility and debugging techniques.
So you see, whether you use a super base class or not, is really a matter of personal opinion, experience and project requirements.
If you like the logging facilities, debugging methods, language loading, class loading techniques and code...then absolutely put it in a base class and save yourself some wiring work when plugging all those objects togather manually.
If your target audience is the greater PHP community - I would suggest going the way of Zend and keeping things independent - cause it seems to be the choice of popular opinion.
Cheers
