I think you misread me:Hockey wrote:Why is it dangerous to use a constructor for object construction? The name alone implies it's very use.
I wrote:Well it's probably quite dangerous to do anything more than required for construction of the object in the constructor.
Yeah I do that too. If there are more than 3 characters so that satisfies my code standard.Hockey wrote:I agree, at least in adding extra namespace to each class name until namespaces are standard part of PHP. Whether three characters or not. I usually prefix my classes with the code name of the project.
You and I do differ there. I have a series of environment objects such as development, production, testing etc. that each pull in their own front controllers and one object that decides which environment to use.d11wtq wrote:I like to do something a bit like what ~ole just did, albeit selecting an approriate controller first.
I don't agree that it is possible for a constructor to create side-effects. It's purpose it to set up the initial state so there was no state beforehand. However it is not the job of the constructor, necessarily, to execute the primary action of the class and given those two responsibilities and I think the difference between __construct() and run() is quite clear cut and it is useful to separate. As for exception handling, I think that problem can be all but eradicated by only placing code that is likely to throw exceptions at runtime in places where it can be easily caught.stereofrog wrote:Good approach, however there are two problems with it. First, it's often hard to separate "what is required for construction" (strictly speaking, nothing) from "what is required for running" (strictly speaking, everything). Requiring the constructor to have absolutely no side effects doesn't seem practical to me. Second, if the constructor fails, where would you handle an exception: in __construct() or in run()?
Sadly not all libraries subscribe to this so how do I avoid collisions with them? I couldn't, for instance, create a class called HtmlReporter in my application because SimpleTest has already defined that. Additionally I don't see the chance of combining multiple applications as an impossibility. Protecting yourself from these problems is an good, easy habit to get into and I see no reason to stop.From my POV, prefixing (aka "poor man's namespaces") is useful for common library classes, not for the application ones, especially the main Application class, which is unique by definition.
The main problem I see with globals is that they can be read and written to from anywhere. This means that if you use globals your entire application it dependent on each any everyone of them. Also it is not obvious where reads and write happen, the whole principle of divide and conquer coding breaks down. It's like having several people working on a small desk, each person is shuffling about bits of paper in a bid to get work done; moving other people's work in the process. As a result the individuals involved are forever losing things they and they keep having to stop and ask each other where x object has gone. In this regard global registries, especially ones accessible via static methods, are not much better.
Even if other platforms/frameworks have used them, statics aren't very object orientated. I've spoken to people working on in relatively fast paced teams who say the average lifetime of a static is about 2 or 3 months and then they need to be replaced and usually they have to resort to lengthy find/replace sessions to do this.
I like to keep my globals down to as few as possible because it's the best leg to start on. If you start your application by using several globals you, or someone else, is going to continue to do so. Similarly is you start by using, several statics as an alternative to globals, then they are probably going to multiply. Both are bad, but unfortunately you've got to have some of them. There's a trade-off here between the two. I'm on the fence. Statics can't be reassigned later but represent poor objectification. I'd say avoid both where possible but they are an inevitability.