josh wrote:I think this mirrors real world objects. In real life you don't just instantiate a House, you can't even look at the whole house at once, its sort of abstract in a sense. So I would just have /House be your abstract class. /House/Wall, and House/Door, and /House/Nails and such would be your 'concrete' objects. Or perhaps /House is your container, which contains a couple /House/Room objects, and /House extends /House/Foundation?
The problem with that is that it leaves the base class
outside of the namespace in the cold
VladSun wrote:Although I use namespaces, I haven't faced such problem yet. I always use Abstract for the abstract classes. Usually, I use single word namespaces - i.e.
But I just tried running "abstract class Abstract{}" in PHP interactive shell, and it threw an error. Maybe that's not what you meant?
VladSun wrote:IMHO, namespaces should not be used as part of the class naming - its purpose is to solve naming conflicts.
In light of that, how do you think namespaces should be implemented in the context of a framework?
VladSun wrote:Also, I don't think having an abstract class in the root of the object hierarchy makes sense - it is an abstraction of what? Sounds like it's an abstraction of the namespace itself.
Do you mean it should be inside the namespace? Then I agree.
Jenk wrote:I am seriously of the opinion these days that abstract classes are foul, and the only thing that should ever be abstracted is an interface (which is redundant in PHP anyway, as of course it is dynamic - happy days!)
Why exactly? What if you have common functionality that doesn't quite work as a concrete class?
VladSun wrote:And if its only interface, I use Interface. If one can put some code to reuse, it's a "base" class.
Christopher suggested "Base" earlier in our discussion. It seems like a good solution.