[iso-8859-1]

Why not use a class? http://pear.php.net/package/Net_Socket

Or at least use namespaces. There is no reason to stick with the native PHP wrappers. It's common knowledge that PHP function names are illogical because of backward compatibility. So why not use a wrapper?

I think it's sad that even after PHP got all these features so that it resembles a proper programming languages, people aren't even using them! Makes me wonder if it was a good decision to force people to use classes in Java...

[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).