/ elang / kernel

Object Expression

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.

BNF:	["/**" docComment "*/"] "def" (String | "_") auditors behavior
XML DTD:	<!ELEMENT objectExpr (DocComment, String, auditors, %behavior;)>
Java:	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.
Example:
in Kernel-E:
in XML:
in Java: