Timeline for PHP my way of threating static classes
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 18, 2015 at 16:20 | vote | accept | maximkott | ||
| Jan 8, 2013 at 15:08 | comment | added | mseancole | @maximkott: You should remove your "answer" and edit your question with that information. I don't understand why you would not want to instantiate a class. That single limitation, and your static solution, is the root of all your problems. "I want some classes be accessible as static ones, but behave like regular classes." That's contradictory, and I cannot imagine a situation where it would be necessary. It really sounds like you want a shared instance of a normal class, (persistence through sessions, cache, etc...) or maybe helper functions. As Corbin said, static is very much anti-OOP. | |
| Jan 7, 2013 at 23:10 | comment | added | maximkott | Read my post below, please. | |
| Jan 7, 2013 at 22:05 | comment | added | mseancole | I wasn't sure whether I should mention autoloading or not, but you are correct, it would be. | |
| Jan 7, 2013 at 21:24 | comment | added | Corbin |
+1, but a small nitpick: Auto loading tends to be much more flexible down the road than explicit require/include. (And it can have very similar performance with a simple autoloader.) The problem essentially boils down to that the $class may have already been loaded. Not likely in a simple case like this though. (And in all but a few edge cases, attempting to double load classes is a very bad sign.)
|
|
| Jan 7, 2013 at 20:19 | history | answered | mseancole | CC BY-SA 3.0 |