An object expression defines the behavior of an object -- how it responds
to an incoming message. The object expression is an expression
because it evaluates to an object with the behavior it defines. It is
the means for defining object behavior in E.
The components of an object expression are:
The docComment serves
the same documentation function as Javadoc class comments. The intent
is both the compile to Java code that Javadocs well as E documentation,
and to produce Doc objects at runtime to support runtime type description
and on-line help. (Doc objects are the object produced by the Javadoc
parser and processed by doclets, such as the Javadoc web page generator.)
The String is the optional
behavior name, or "_" if absent.
It serves the same function as Java's fully qualified class name,
including continuity across upgrade (both serialization-upgrade and
live upgrade), documentation generation, and default (Miranda) object
printing behavior. If the behavior name is absent ("_"),
its instances cannot be serialized, unserialized, or upgraded; documentation
will not be generated (If there's a docComment anyway, a warning
should be generated), and the Miranda printing behavior will simply
be to print "<e object>". A debugger's
eye view of these instances is almost certain to be less informative
as well, but that's outside the scope of this spec.
If the behavior name is present, it will be interpreted as a sequence
of segments separated by "."s. All but the last of
these segments will be interpreted as package names, and should correspond
to the relative directory path from the source root in which the current
source file is found. The last segment is interpreted as the containment
path. It is further interpreted as a sequence of segments separated
by "$"s, and should correspond to the lexical nesting of
object expressions. No two object expressions should use the same
behavior name. We do not yet specify what happens when these conventions
are not followed, but currently such programs will be rejected.
The auditors check
whether this object expression's parser tree has whatever property
they audit for.
The behavior contains all the object's actual
runtime behavior -- its response to messages.
An objectExpr is a methodicalExpr
when the behavior is a eScript.
An objectExpr is a plumbingExpr
when the behavior is a matcher.
"*/"] "def" (String | "_") auditors behavior
(DocComment, String, auditors, %behavior;)>
The DocComment is output directly as the same DocComment, except
that we may yet define some tag transformations.
If the behavior name is present and conforms to the above conventions,
then a top level object expression compiles to a Java "public
final" class, and a nested object expression compiles to
a Java public nested class, not an inner class.
In other words, it compiles to a class declared "static public"
inside the scope of its containing class, but not inside the scope
of any methods or instances. At the position in the generated
Java code corresponding to the appearance of the object expression
we generate a call to the nested class's constructor, so the nested
class must appear textually earlier.
If the behavior name is absent ("_")
we synthesize one that follows the above conventions but whose
last segment (the one after the last "$") is a number
unique in this context. This corresponds to the Java convention
for anonymous inner classes, even though we're generating a nested
rather than inner class. After compiling the Java to bytecodes,
it would be good to mark these names as "synthetic"
in the .class file.
The auditors do their audit prior to the code being translated
to Java, and the results of the auditing protocol are kept elsewhere
in the TCB without needing compiler support.
Finally, the behavior is compiled in Java code, as described
in methodicalExpr and plumbingExpr.