The Developer's Assistant
Presented to SCOUG Febrary, 2009
I think we had a good meeting even overcoming my surprise at jabbing the
felt tip of my black erasable marker down into the unit. I need to
start off less enthusiastic in the future. Fortunately I had backup
colors and could continue.
The Developer's Assistant(DA) provides a "true" Integrated Development
Environment where the "integration" occurs intrinsically through design
in which any functional extension arises naturally from within an
existing infrastructure. Thus it differs from a current approach like
All "external" input, e.g. keyboard and file transfers, comes into the
GUI editor. The GUI editor under the direction of the developer
"assists" in selecting and retrieving "internal" input from the Data
Directory/Repository. Under the direction of the developer the GUI
editor directs the "output" of the current possibly modified
source--text, code and data--to the DD/R.
Somewhat clumsily we can depict this as
We did not touch upon the aspect of "File Transfer" in the meeting. I
will do so here.
Remember that the DD/R is a single source library of text, code and
data. Consider the possibility that someone wants to share, i.e.
transfer some or all of their DD/R to yours. Unlike other libraries,
source or not, which have compatibility issues, characteristics such as
exist with current OO class libraries, the DD/R has none in any DD/R to
DD/R transfer. Why they don't and moreover cannot occur requires a
deeper understanding of the DD/R.
I have discussed before the creation of unique names consisting of two
parts with an text prefix, e.g. 16 bytes with a full word, e.g. 4 bytes,
numeric (binary) suffix, in this instance for a total of 20 bytes.
Entries which do not have a name associated with them by the developer
get one assigned by the DD/R. Thus every text (sentence), code
(statement) and data (referent) element and assembly has an "assigned"
unique name created and maintained by the DD/R.
The DD/R only stores text, code and data elements, the "raw material" of
references (text and code) nad referents (data) in "native" form. All
assemblies exist as "named", ordered lists of elements and assemblies as
occurs in a Bill of Material(BOM) in manufacturing. We have an element
storage "area" for text and code, one for data elements, one for text,
code and data assemblies, and one for data assemblies (data aggregates
of arrays, structures and lists).
No desire to confuse here. We can have an assembly of text, code and
data. Each "ordered" entry within it will be either an element or an
assembly. If a data element, it will have the unique name of the data
within the data element storage area. If a data assembly (array,
structure or list), it will derive from the ordered list in the data
assembly storage area.
Thus all text and code assemblies will exist with the text and code
assembly storage area along with data element and assembly names. The
data assemblies, however, will only appear in the data assemblies
The repository contains the single directory and the currently defined
four storage areas. All unique names of text, code and data elements
and assemblies appear in the directory as do all requests to the DD/R.
Thus along with storing the unique name the directory must also indicate
its "type" as text, code or data and either element or assembly.
Given that the use of the numeric suffix of the unique name means that
we have a builtin versioning system, instrinsic and not optional, we
have a solution for homonyms (same name, different reference). We need
a similar solution for the instance of synonyms (different names, same
This requires an additional storage area in the repository, the "alias"
storage area, Of the set of names for an entity we designate one as the
"real" name with any other as an "alias" only. Thus the directory must
also designate aliases when they occur. Use the alias name to determine
the "real" name and then retrieve on that name from the proper element
or assembly storage area.
At this point we have covered all the possibilities of text, code and
data elements, assemblies, homonyms and synonyms (aliases). Thus we
have covered "all" that can occur as "source" within our coding efforts.
This suffices in dealing with any hierarchically ordered list, i.e.
one without loops.
Software differs from other "standard" manufacturing processes in that
it permits loops, which transforms a hierarchy into a network. We have,
for example, the instance of co-routines where either may invoke the
other repeatedly in the execution of the process in which they
participate. Another occurs in "recursion" where a process my invoke
Thus where we desire a visual presentation of networked processes we
have to allow for, i.e. represent, the loops with may occur among
processes or those as in recursion which may occur within a process. We
don't need this storage area within the repository for the moment, but
will develop it later when the need arises.
Also we have a need for none text, code and data entities like projects
and sub-projects, e.g. OpenOffice and its integrated component entities.
These need a unique name and type assignment for the directory. As
these are inherently assemblies we can store them in the text, code and
data assembly storage area.
As we use a Database Management System(DBMS) for the DD/R we will
develop the functionality it requires to properly support the DA. We
need the ability to create, delete and modify entities, the ability to
"normalized" source code, i.e. eliminate spaces, to insure a common
unique name for the same statement regardless of developer
"eccentricities", to provide a "standard" output, i.e. one with spaces
for readability, for source code, to insert "/*" and "*/" delimiters for
text to appear as comments in source among others.
At the same time we want to take full advantage of the DBMS to engage in
"data mining" of the repository. For example to take the alias entries
and replace them with the "real" wherever they occur in source
assemblies. In the same manner we may want to iteratively reduce the
number of homonyms by selectively assigning them more "meaningful" data
names and have those changes occur throughout the source and possibly
In short we want to be able to come in after the fact to make
modifications for more "sensible" readability of source text, code and
data without, one, setting precondition restrictions on input to the
library (repository) with respect to names or, two, having to manually
go to each instance while seeking to impose a "freeze" while
The DD/R supports literate programming, reuse down to the text, code and
data element level, integrates text, code and data within a single body,
and provides all the "data mining" functions available with the DBMS.
As an exercise to the reader consider how you can engage in a file
transfer from one DD/R to another when the rules governing the prefix
and suffix sizes of the unique names differ. Bear in mind that while
such transfers cannot result in any incompatibility, an assertion which
we will have to prove by exposition, you can nevertheless introduce
"contradictory" logic. Thus compatible and contradictory do differ.
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2009 The Southern California OS/2 User Group. ALL RIGHTS
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.