The Developer's Assistant

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

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

    DA
        GUI editor
           Input
               Keyboard
               File Transfer
               DD/R
           Output
               DD/R
		File Transfer

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

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

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

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

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

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.

Copyright 2009 The Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.