Re: Entity and Identity

On Jul 23, 6:43 pm, Nilone <rea..._at_gmail.com> 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 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.

> 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?

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;

        virtual void Close() = 0;
        virtual void PostTask(Task*) = 0;

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

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:

http://en.wikipedia.org/wiki/Algebraic_data_type

> 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. Received on Fri Jul 24 2009 - 01:31:05 CEST