[SeoxyS]

You seem to be under the assumption that classes are always categorically better than a procedural API. I think you're mistaken. Classes aren't always a good abstraction.

Classes being a good abstraction:

    $user = new User('John', 'Doe');
    $user->authenticate($token);

Classes being a bad abstraction:

    $two = Math::add(1, 1);
    // or worse:
    $math = new Math;
    $three = $math->sqrt(9);

In that latter case, you'd be much better served using a functional or procedural API, even if it's namespaced:

    (+ 1 1) ; two
    (math/sqrt 9) ; three

If you're going to argue that `stream_socket_` is doing it wrong, I'd like to hear why it'd be better as a OO API.

[hythloday]

1.plus(1) looks quite sensible to me (every vector/matrix library I've seen has had a v.plus(v) or m.times(m) that returned a copy), though obviously sugar improves it. Sugar is irrelevant to OO vs procedural though.

OO is a good way to think about sockets because sockets are state machines. There's nothing wrong with passing around a socket called "this" to every procedure, but if you're doing that then you're just doing OO clumsily (i.e. without the benefit of being able to transparently substitute an SSL socket at a later point in time).