I assume you are talking about fopen-type of functions that are nothing more but wrappers around C standard library functionality.
Use SplFileObject (part of SPL that is part of PHP core) for object-oriented way to manipulate files. On a failure (like your permission issue) it throws Exceptions and if not handled this will result in a "hard" error with a backtrace log.
Awesome, thank you. I'm a bit rusty on best practices since I've shifted my focus away from php, but it's nice to know that options to make it behave a bit more high level exist.
What's wrong with singletons in general and why would an object could not assume single responsibility (consider an UIApplication singleton on iOS)? I thought, contrary to what you stated, they solve the issue of global variables rather than introducing new ones.
That class extends SPL ArrayObject class which provides array-like access syntax (operators). It does not mean it has to act like an in-memory array, it could read data from disk, session, database or whatever. Delegating this kind of functionality to a single array would simply not work without further abstraction.
Singletons don't solve problem of global variables, they are global themselves.
They are global shared state than can be unexpectedly accessed from any place in the program.
Encapsulation provided by singletons makes them even more problematic than global variables. You can temporarily overwrite global variable, run function that uses it, and restore global value. Singletons can be designed to prevent that, which kills testability of code that uses singletons (e.g. when you need to replace global DB connection with mock object).
Singletons are global variables++. Read up on the capability security model and ambient authority (Mark Miller's erights.org, Gilad Bracha's Newspeak, Mark Miller's JS work eliminating accessibility of document etc. singletons for safely eval'ing JSON etc.) to understand the security, composability, testability and modularity issues with these idioms.
I don't know the particulars of how PHP's ArrayObject works, but take Ruby for example: instead of inheriting from Array, to make a class that operates like an array, one mixes in the Enumerable module (similar to a trait) and implements an "each" method to handle the low level access. All of the other methods come along with the module. In this way, the lineage of a class isn't important; rather, it's what it actually does that matters. (How meritocratic! :-)
But particulars of any language aside, I think this is an important step for PHP. Once a language gives the ability to compose the behavior of a class through traits, modules, mixins, etc rather than standard inheritance, it becomes easier to separate the data that a class encapsulates from the behaviors that it provides—and that, I believe, leads to more modular code.
Not sure of what kind of legacy features you would want to be removed but it's not like they are just building on top without thinking.
PHP 5.4 will also drop:
- safe mode
- register_globals
- allow_call_time_pass_reference/y2k_compliance and other legacy ini stuff
- "continue 123" syntax (can be replaced with goto). As far as I recall this is done since it's barely used and if removed would allow to implement some opcode performance optimizations.
Dropping some PHP 4 era syntax is obviously out of question due to already mentioned webhosting and backwards compatibility issues.
Use SplFileObject (part of SPL that is part of PHP core) for object-oriented way to manipulate files. On a failure (like your permission issue) it throws Exceptions and if not handled this will result in a "hard" error with a backtrace log.