Re: Entity and Identity

On Jul 23, 6:30 am, David BL <davi..._at_iinet.net.au> wrote:
> 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?

The problem is that "appropriate use" always requires limiting which features of OO you apply. Implementing interfaces are fine, but that should be extracted into a separate mechanism so that it can be used safely. There are other appropriate uses that could, and should, be formalised. Each aspect of OO was meant with good intentions, and works individually, but not together.

It is easy to contrive an interface to a flushable output stream by passing around pointers to shared memory containing executable code and space for buffers and whatever else you want to do. It would be safe when used appropriately. BTW, GOTO is useful too, when used appropriately.

The point is, if we're going to have abstraction mechanisms, it needs to be the right mechanism. The relational model is an example of such. It works for any composition of its features. The user may not understand the model, and thus the consequences of how they use it, but that is not the fault of the model. The information is available, and the consequences of applying the model is clearly defined.

With OO, only a very specific subset of the possible compositions of its features are valid and useful. Using some features together breaks the promises made by the abstraction mechanism, i.e. it violates its own reason for existence when used incorrectly. And doing is so is very, very easy.

I believe programmers will be best served by completely discarding OO as currently understood. Received on Thu Jul 23 2009 - 12:43:13 CEST