Re: Entity and Identity

On Jul 22, 10:36 pm, Nilone <rea..._at_gmail.com> wrote:

> Your counter-argument boils down to an appeal to popular opinion,
> which is not a valid argument. I'll answer it anyway. I should note
> that when I rail against OO, I mean class-based OO with inheritance
> and overriding.

That's an interesting point because in my experience the best OO programmers only tend to subclass pure abstract base classes (at least where virtual functions are involved). In other words, subclassing has more to do with subtyping than inheritance (of implementation).

On another note, mixins (i.e. classes templatised on base classes) appear to avoid many of the pitfalls of conventional inheritance. For example, they eliminate the need for multiple inheritance. Nevertheless again, the best OO programmers prefer simple composition to achieve code reuse.

I think there is a huge variation in the practise of OO. It is obviously a dangerous tool to wield. Despite this I believe there are many valid uses, even if they are hard to find amongst all the horrible implementations out there.

A good application of OO: A pure abstraction for a flushable output stream:

// C++
struct OutputStream
{

    virtual void write(void* buf, int cnt) = 0;     virtual void flush() = 0;
};

This allows for connecting one of many different 'suppliers' - i.e. implementers of the interface to one of many different 'clients' that can use the interface. This connection can be achieved at run time even though client and supplier are compiled and linked in isolation. Note that buffering the entire output may not be a viable alternative which seems to imply that the client must make calls on the supplier.

That to me is what best characterises OO. It's not clear to me what alternatives exist. For example, I'm wondering whether there's an approach that achieves a similar degree of decoupling in a pure functional language. It seems unlikely to me because an implementer of an output stream must surely be regarded as a state machine. For example, consider an open socket connection. I fail to see how one can think of it as an abstract value, nor indeed an assignable variable that holds an abstract value. This is indeed where I dispute Paul's comment elsewhere:

    "The popular OO programming techniques/languages     commonly depend on assignment, no matter how much     they pretend otherwise."

I understand and respect what Paul meant by that comment. However I think he has missed the point that OO systems are composed from state machines where assignment often becomes an implementation detail, and indeed assignment of state is unable to model the inner workings of objects that perform I/O with devices like hardware clocks, disk drives, printers, and network cards. In addition, a computing model based solely on assignable variables is inappropriate to model threads, thread pools, thread schedulers, mutexes, semaphores etc, because these all interact with the CPU in special ways (e.g. in order to initiate a context switch or to execute a memory fence instruction).

I conclude that OO can be useful for systems programming. But is it any good for "application programming", and can the distinction be formalised? Received on Thu Jul 23 2009 - 06:30:57 CEST