Java Names

For purpose of addressing the design of Igneous-P, this note will identify "Java Names" as denoting the set of user-specified names within a Java program - therefore excluding Java keywords, in the context of this note.

Java Syntax

(Refer to JLS)

Common Java "Best Practice"

The Java programming language uses a convention of syntax and naming, colloquially referred to as camel case.

As examples of "Best Practice" in the Java programming community:

• Class Names - e.g. Granite
• Method Names - e.g getGroundcoverType
• Instance Field and Parameter Names - e.g flowRate
• Static Field Names - e.g GEO_EPOCH (or alternately, regular field/parameter name semantics),
• Package Element Names - e.g "materialsAnalysis" in package name "mountain.materialsAnalysis"

Transforming Java Names Within the Common Lisp Symbol Namespace

Igneous-P may support at least three modes of Java name transformation, for interpretation of Java names within the symbol namespace of a Common Lisp implementation:

1. Intern without readtable case transformation. "FooComponent" => |FooComponent| (always)
2. Intern with readtable case transformation, as by read-from-string. "FooComponent" => FOOCOMPONENT (as in an upcasing readtable)
3. Caps-to-hyphen transformation, naturally with readtable case transformation. "FooComponent" => FOO-COMPONENT (as in an upcasing readtable)

....insofar as class names.

Sidebar: Interpretation of Java Package Names

Needless to say, a similar kind of name transformation will need to be performed with regards to each lexical element of a Java package name, such as "waterway" and "riparianHabitat" in a Java package name, "waterway.riparianHabitat"

Sidebar: Java Packages as Common Lisp Objects

Thirdly, the Igneous-P design must address_ the interpretation of Java package names, likely in interpreting Java packages as objects in the Common Lisp namespace - likely, in a methodology involving interpretation of each Java package as a Common Lisp package, optionally defining a manner of structural relation among Common Lisp packages interpreted thusly, in such structural relation as may be interpolated based on package name lexical elements in the Java namespace

Central: Selection of Name Transformation Methodology

Igneous-P may be designed as to allow the user to select one of those three name translation methods, as at each of:

• compile time or system load time
• for purpose of runtime evaluation, namely either:
  • in a lexical runtime scope, or
  • in a global runtime scope.

In the interest of ensuring equivalence between interned compile-time and runtime names, Lupine-P may limit the selection of name transformation methodology to the moment of system compilation or alternately, system load.

Portability of Interpreted Java Names

In the design of Igneous-P, it would be desirable to ensure that user code may be portable, without regards to the Java name translation methodology being utilized at any one time.

The Function, INTERN-NAME

Design Discussion: Selecting Context for Selection of Name Transformation Behavior

During the initial design of the function, INTERN-NAME, consideration was made as for whether to allow selection of the name transformation behavior at runtime, or alternately to "hard-wire" the selection of the name transformation behavior such that it would be determined in a constant manner at time of system compilation or initial system loading. In the first case, the behaviors of the name transformation behavior could be configured with a keyword argument to the function, INTERN-NAME, such that the value of that keyword argument would default to the value of a special variable, *NAME-TRANSFORMATION*. In the second case, INTERN-NAME would be defined unique to the value of a constant variable, +NAME-TRANSFORMATION+ - that variable then serving only an informative role, as within the runtime environment.

In the interest of ensuring equivalence between interned compile-time and run-time names, the consideration was concluded with a decision as to define the name transformation behavior as a constant feature. +NAME-TRANSFORMATION+ will be defined as a constant variable. The behavior of the function INTERN-NAME will be defined as being unique to the value of +NAME-TRANSFORMATION+, when the function's definition is evaluated.

+NAME-TRANSFORMATION+ (Constant Variable)

• See also: INTERN-NAME