Hacker News Reader

Comment by AndrewO | Hacker News Reader

It makes my skin crawl to see the first example use case be combining inheriting from singleton and the array class. It looks like PHP is finally getting advanced OOP features and the first thing someone wants to do with them is make a singleton (which violate single responsibility, also introducing global variables and tight coupling) that extends arrays (when delegating to an array instance is usually a better choice).

I know this is a single example, but I feel like I've seen bad OOP practices in PHP so many times in the past. This is such a rich feature but it brings with it a lot of potential for misuse.

View on HN

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.

In addition to what the others said, these two pages make the arguments that convinced me:

http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140...

http://www.c2.com/cgi/wiki?SingletonsAreEvil

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.

"In this way, the lineage of a class isn't important; rather, it's what it actually does that matters. (How meritocratic! :-)"

    In Ruby, no one cares who your parents were, all 
    they care about is if you know  what you are 
    talking about.

  - Logan Capaldo

Reply on news.ycombinator.com