Re: Entity and Identity

From: Nilone <>
Date: Fri, 24 Jul 2009 04:11:51 -0700 (PDT)
Message-ID: <>

On Jul 24, 1:31 am, David BL <> wrote:
> On Jul 23, 6:43 pm, Nilone <> wrote:
> > 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.
> I'm associating OO with *any* approach (however carefully formalised)
> that involves identifiable state machines that tend to be accessed
> through function/procedure calls in a way that supports dynamic
> polymorphism.   I don't consider "OO" to be defined by the current
> suite of mainstream languages out there.

I'm opposing OO as implemented in the current suite of mainstream languages - more specifically, I'm opposing the class systems of mainstream languages. I have no problem with state machines.

> I don't understand in what way implementing and using interfaces can
> be made "safe" by extracting into a "separate mechanism" that
> presumably is no longer OO.  If that's what you mean you're going to
> need to justify such a bold statement!
> > 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.
> Can you give an example?   I don't mean an example of a poor
> application of OO (they're everywhere), but rather an example of two
> aspects of OO that don't work together in general and why you think
> that is bad.

The point is that OO class systems are broken in the sense that they allow known poor applications, due to their conflation of the concepts. So far, I can see three concepts combined into the idea of classes: interfaces, types and state machines. OO classes allow one to create things which are none of the above, in which case any code which operates on objects as one or the other is likely to fail eventually.

> > 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.
> I fail to see the point you're making here.  My point was that OO was
> a natural fit for the concept of a state machine representing an
> output stream, and FP, LP, RM+RA are not.   The implication is that OO
> is sometimes useful.  You appear to be arguing that OO is never
> useful.  Is that right?

No, I'm saying the current implementations of OO classes cause too many issues to make them worth the effort. Nearly all available OO documentation leads one away from a clear understanding of the issues.

> An OO style language makes it relatively easy to directly express the
> concepts of 1) defining the state machine interface, 2) implementing
> the interface and 3) using the interface.
> The following might be a better example:
>     struct Task
>     {
>         virtual void Execute() = 0;
>         virtual void Abort() = 0;
>     };
>     struct ThreadPool
>     {
>         virtual void Close() = 0;
>         virtual void PostTask(Task*) = 0;
>     };
>     ThreadPool* CreateThreadPool();
> Note that the execute and abort methods on an abstract task have no
> "data exchange" whatsoever (they takes no arguments and have no return
> value).   For that reason an abstract task is hardly going to map into
> a "data centric" language (such as a pure FP language).
> I think thread pools are a useful concept and OO is a very good fit.
> > 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.
> If you're saying that the RM is a well defined mathematical formalism
> whereas OO is not then I completely agree.
> It's not clear what you mean when you imply that the consequences of
> using OO aren't clearly defined.  For example, with effort one can
> write OO programs in a particular language and construct proofs of
> correctness against requirements.  Nondeterminism isn't the problem!
> Difficulty of writing correct programs is the killer.

OO classes as a type system doesn't prevent subtypes from breaking existing working code, and can't be relied on for the purpose for which they are intended.

> I hope you're not suggesting that the RM is always "the right
> mechanism".  Even in the arena of data representation and manipulation
> it is poorly suited to algebraic data types:

The RM doesn't strive to be everything. It is an exceptionally useful tool with wide application in programming. Current OO implementations strive to be everything to everyone.

> > 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.
> I don't find your argument persuasive.  I would simply say that OO is
> (only) well suited to a narrow problem domain.  Since programming
> general purpose state machines is very difficult it stands to reason
> that OO should only be used by competent programmers in those
> instances where it is appropriate.

State machines are great. I'd be happy enough if OO, as commonly understood and implemented in mainstream languages, were limited to state machines. Received on Fri Jul 24 2009 - 13:11:51 CEST

Original text of this message