The article "object vs. class" by Aleksandr Gofen, "improved" by Dr Manfred Mackeben, [Delphi Informant Vol 5 No 7, July 1999] is a disaster. Besides being poorly organized, the article is incorrect in its statements on scope, global variables, the use of constructors and destructors, memory management, class hierarchy development, inheritance, and polymorphism. Given limited time and space, it is possible to comment on only a few flaws in detail.

The premise of the article is that the obsolete OP object hierarchy is still a viable, and even desirable, path for development, over the class hierarchy. This is incorrect; the object hierarchy is kept for backward compatibility, not for the development of new code. The two hierarchies are incompatible; an object instance cannot be assigned to a class instance, and vice versa. Thus, if one uses the object hierarchy, one simultaneously rejects the significant OP language advances made since BP7, as well as the the capabilities of the VCL classes, and introduces confusion into the programming process.

It is obvious that little, if any, review was made of the article. Consider this extract: an attempt to define objects for complex arithmetic.

TAlgCmplx = object
  Re, Im: Extended;
  Procedure Conj;
  Procedure Init(const x, y: Extended);
End;

TExpCmplx = object
  Re, Im: Extended;
  Procedure Conj;
  Procedure Init(const rad, fi: Extended);
End;

Given the types shown in Figure 1, the following functions perform operations on complex numbers:

function AlgOper(const z1: TAlgCmplx; const op: Char; const z2: TAlgCmplx): TAlgCmplx;
function ExpOper(const z1: TExpCmplx; const op: Char; const z2: TExpCmplx): TExpCmplx;

and functions:

function ExpToAlg(const z: TExpCmplx): TAIgCmplx;
function AlgToExp(const z: TAlgCmplx): TExpCmplx;

transform one format into another. With these functions, it's easy to use arithmetic expressions with complex numbers. For example, the mathematical expression
             (zi - z2)/(z3 + z4) 
may look like:

AlgOper(AlgOper(zl, '-', z2), '/', AlgOper(z3, '+', z4));

That is, the article recommends that complex numbers be defined as two separate types, without constructors and destructors. This is absurd; a programmer/maintainer can easily be confused as to which representation he is working with; a single representation of TComplex is the only reasonable approach.

Two representations not only confuse a programmer, they confuse the compiler. Since OP doesn’t know enough to provide the appropriate function at the appropriate time, several versions of AlgOper() must be written to account for the different ways it can be called:

function AlgOper(const z1: TAlgCmplx; const op: Char; const z2: TAlgCmplx): TAlgCmplx;
function AlgOper(const z1: TAlgCmplx; const op: Char; const z2: TExpCmplx): TAlgCmplx;
function AlgOper(const z1: TExpCmplx; const op: Char; const z2: TAlgCmplx): TAlgCmplx;
function AlgOper(const z1: TExpCmplx; const op: Char; const z2: TExpCmplx): TAlgCmplx;

but this presents another problem that has not been thought through: there is no way to overload the return types such that a TExpCmplx can be returned.

There should be no need of external functions to convert from one representation to another. Following the principle of encapsulation, a function can be provided to return the instance in whatever form is desired. However, the guts of the object, which should be private, are actually severely public.

And writing a string interpreter in the middle of a numerical computation is just silly.

That this article actually made it into print is a mistake for Delphi Informant, and may confuse new Delphi practitioners. Readers are urged to skip it entirely.