One of the types of entities is the object. An object is an entity that acts has a container for other named entities. These named entities are its members. Every object has a type also known as a class. The object's type describes what members it contains and what type they are. Just as an entity may be named or anonymous so to the type of an object may be named or anonymous. An object is one of the two types of entities and their are two types of objects. As a form of entity, object names may not always refer to the same object. Limits on this flexibility are placed by types. An object name may only be assigned an object value if it is of a compatible type (see 5. Inheritance).
A named object is an object with a name. Named objects are one of the two types of named entities that may be members of objects.
The most common type of object is named with an anonymous type. The syntax for this is:
access-modifier name :super-type :interface-1, interface-2, ..., interface-n
{
object-body
}
Anonymous type objects are described by an object body. This is a group of entities and statements enclosed in curly braces. The object body describes each of the members of the object. The object's type is an anonymous sub-type of the stated super type and implements the declared interfaces. It is possible to interact with the object's unique members even though its type can't be stated because a unique name has been given to the object.
Object names of this form cannot be assigned new values because a unique anonymous type is associated with the the name and there is no other object of that type to be assigned to the name.
Object bodies are literally the object. The compiler translates them into the actual object. This form of object is not provided in many object oriented languages. Java's anonymous inner classes have a similar effect. Note that in Java one is still describing a class, which is a form of pattern, then instantiating an object from it.
In addition to members an object body may also contain statements to be executed. These are its creation code. These statements will be executed when the object is created. Creation code is executed from top to bottom along with the initialization of other contained entities.
access-modifier name :super-type :interface-1, interface-2, ..., interface-n
{
entity-1
statement-1
statement-2
entity-2
statement-3
}
In this example, entity one would first be initialized then statements one and two would be executed. Afterward entity two would be initialized and finally statement three would be executed.
In the case of object bodies, where one is literally writing the object, creation code can be a little confusing. One way to look at it is that as the compiler translates code into an object it performs the actions of the creation code. In this sense creation code is only a more powerful way to express the initial state of an object.
A destruction block allows the execution of code when an object is destroyed. Destruction blocks are introduced by the keyword 'destroy' followed by a block in which code to be run will be executed, as:
access-modifier name :super-type :interface-1, interface-2, ..., interface-n
{
destroy
{
destruction-statements
}
}
There may only be one destruction block per object. They are essentially a special method that is called on the object before it is deleted (see 11.3 Methods). Members may or may not have been destroyed already and in general it is not safe to assume properties still have valid values. Members of primitive type are an exception and are guaranteed to be available during destruction. Because of ASAP garbage collection in Opal it is safe to assume that objects will be destroyed shortly after their last use and before the program terminates.
Note that it is not possible to resurrect
an object as it is in Java. That is to say that the destruction block must not save a reference to the object anywhere. If it does the result is undefined. The compiler will attempt to provide warnings and errors to prevent this but the compiler may not be able to guarantee it won't happen so the programmer must be careful not to as well.
The second form of named object are those objects with a named type. The syntax for this is:
access-modifier name :super-type = expression;
Interface types are not allowed for this form of object. This is because an object can be dealt with through only one type at a time. The object name receives its value from an expression. The expression is terminated by a semicolon because the whole line forms an assignment statement. This form of object is a combination object declaration and assignment statement. The expression must yield an object of the correct type (indicated by the super type). The object name may be assigned to other object values of the given type at later times. The assignment statement may be omitted so long as a value is assigned to the object before it is used. The syntax for this is:
access-modifier name :super-type;
If the type were omitted it would lead to many pathological cases. The super type is always required to be listed.
Anonymous objects have the same forms as named objects. Anonymous objects are not declarations but instead form expressions (see 6. Statements & Expressions). Just as with named objects there are named types and anonymous types. Remember that the super type colon is always required with anonymous objects
Anonymous objects with anonymous types form object literals. An object literal is an object value which is directly expressed. Just as the number '2' is the literal representation of the object for two. These objects and their object bodies act just as named objects do but instead occur in expressions and yield the object they describe as their value. Their syntax is:
:super-type :interface-1, interface-2, ..., interface-n
{
object-body
}
Anonymous objects with named types are conversion expressions. A conversion expression can be used to change the type of an object. Similar to a cast in other languages. A conversion expression can only be used to convert to a type which can be allowed at compile time. This is because it follows the semantics of assignment, including type conversions and overload disambiguation. Conversion expressions have the form:
:super-type = expression
The expression is converted to the given type. Parenthesis will often be required around the expression if it is to be used in a larger expression because of the low precedence of the assignment operator. As a more concrete example consider this statement:
x = (:double = i) + y;
Here the integer 'i' is converted to a double before being added to y. This example is not very useful because the conversion would be carried out anyway.