JavaNames - GazeboHub/igneous-p GitHub Wiki
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:
- Intern without readtable case transformation. "FooComponent" => |FooComponent| (always)
- Intern with readtable case transformation, as by read-from-string. "FooComponent" => FOOCOMPONENT (as in an upcasing readtable)
- 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.
INTERN-NAME
The Function, 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