SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Mon, 26 Feb 2007 12:21:02 -0800
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Whither Open Source and OO

Content Type: text/plain

I want to make sure that two possible misconceptions do not
occur. The first relates to the origins of open source. The
second to an implication in OO that previously objects did not
exist.

Originally open source came into play prior to closed or
proprietary source. It existed throughout the IBM user
community as reflected in the libraries available from its two
mainframe user groups, commercial (GUIDE) and scientific
(SHARE). It also occurred with the professional associations
like the ACM which published submitted "algorithms" in its
month publication, Communications of the ACM. Moreover as
anyone who has invested in the "Fundamental Algorithms"
authored by Donald Knuth know the vast amount of source
code contained therein. Then in a period between 1956 and
1966 a considerable number of application, communication, and
operating systems written by IBMers for clients but exchanged
among all occurred.

It was only when Boole & Babbage challenged IBM's offering
of a "free" system performance measuring and maintenance
service that the current shift to proprietary, i.e. for profit,
software came about. Thus open source has a history which
overlays as well as precedes that of closed.

To the second point. Let's make clear that no other form of
programming other that object-oriented has ever existed.
Objects are data, either elements or aggregates. We didn't
call the industry "data processing" in the belief that it was
somehow oriented toward something else.

The "current" OO methodology used, for example, in C++ and
JAVA replaced the "previous" OO methodology still in use by C
and PL/I. It short it was OO yesterday, today, and tomorrow
as long as we are processing "data".

I bring these two, open source and OO, up together for a
purpose. I felt the need to further address the "poison pill" of
inheritance, that single characteristic which required a
hierarchy of classes culminating in a class library.

Now a hierarchy of classes implies one or more paths from the
"root" class. This says for two libraries to be compatible they
must have the same classes (same definition of data objects),
the same paths, and the same associated methods. While
different versions of the same method may exist in the same
or different paths, they must be identical in all respects for
compatibility. If they are, you don't need more than one
definition of a class library. Thus the pressure for a
"standard" class library.

Let's make clear that previous OO methods, that used by C,
PL/I, COBOL, FORTRAN, etc. never had this compatibility
problem. For example, processing of a given data object
(class instance) could invoke method 1 from column A for part
of its processing and the method 2 from column B for the
remainder. Perhaps the most common package for which this
occurred was the Scientific Subroutine Package from IBM and
different versions of same from other vendors.

As a result I can't be opposed to OO programming, because I
have no other choice. I can, however, be opposed to its
current "dominant" form with its overly restrictive
implementation of "inheritance". While imitation may be the
most sincere form of flattery, we should not accept verbatim
all ideas sourced from XEROX PARC (Palo Alto Research
Center). We could have avoided the inheritance wars waged
among class libraries and the financial damage which occurred
if we had been somewhat less quick to accept yet another
"silver bullet".

SL/I doesn't use inheritance. Instead for a data object (class)
it offers a "range" attribute. That range attribute contains
the list of methods acceptable for the processing of that
object. It can even specify another data object to create its
own inheritance path. Or it doesn't have to specify any.

Each data element can have an associated "range" attribute.
That range attribute can specify the rules which govern the
elements processing. It can, for example, specify the "range"
of values which the element can assume. It can specify which
values it can assume based on the value of another element
in another, possibly different class instance. In that manner
move the data or referential integrity rules now kept by DBAs
within the database manager, e.g. DB2, into the source as part
of the data declaration.

The "range" attribute then establishes the rules-base which
the software and not the programmer writes the
corresponding source for each use instance. Thus, for
example, if we have a defined data object (class) with an
embedded set of "range" attributes, any use instance of that
object will generate "all" the supporting, rule-based source.
This eliminates the need to rely on either a programmer's
knowledge or remembering of the rules.

Furthermore given the implementation of the data
repository/directory any change to any data object definition
with respect to its content including attributes can trigger a
synchronized update to all use instances across all application
systems as a single unit of work.

Remember the goal of eliminating backlog, of implementing
changes on average faster than they occur.

Thus we can have a class library without a hierarchy,
methods without inheritance, and the ability to customize
inheritance according to whim. That allows us to use any
method with any class in any manner which we choose.

You can take one from column A and another from column B.
That solves the issue of incompatibility.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 26 | February | 2007 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.