Andromeda

Andromeda is an object-oriented, imperative scripting language that extends Blizzard's Galaxy language. It was designed to be an extension to Galaxy in the manner that vJASS was an extension to Warcraft III's JASS scripting language. Andromeda is implemented as a superset of Galaxy, meaning that all syntactically valid Galaxy code is also syntactically valid Andromeda code (the only exceptions are cases where the Galaxy code uses one of Andromeda's keywords). Moreover, Andromeda is compiled directly to Galaxy, allowing custom maps that use Andromeda to be played on Battle.net without the use of third-party mods.

Goals

Andromeda's main goals are to:

• Maintain compatibility with native Galaxy code
• Support object-oriented programming (OOP)
• Support comprehensive and useful reporting of compile-time errors
• Introduce common programming features absent from Galaxy
• Reduce the need for unnecessary and boilerplate code
• Produce optimized code in the target language when compiled
• Provide simple and effective methods for code debugging

Design Paradigms

Andromeda is an object-oriented, procedural, and imperative scripting language with additional support for generic and (limited) reflexive programming. First and foremost, Andromeda adheres strictly to the tenets of Object-Oriented Programming (OOP). Procedural programming, while still supported, is included mainly for compatibility purposes with Galaxy. In Andromeda programming, an emphasis is placed on viewing the program as a collection of objects, each with its own state. Code is built around querying objects to determine their states and manipulating objects to change their states. This allows for the adoption or expansion of programming strategies such as:

• Encapsulation
• Modular Design (also known as Reusability)
• Extensibility
• Orthogonality

Language Features

Andromeda retains all of Galaxy's syntax features while adding new ones. Most of the new syntax is inspired by or directly borrowed from the Java programming language.

New Syntactical Features

Andromeda supports certain syntax found in C/C++ and Java that is missing in Galaxy, including:

• Block commenting
• Function/Method overloading
• Multiple variable declaration on one line
• Expanded implicit cast support
  • string to text
  • bool, int, fixed, char, byte to string or text when using the concatenate (+) operator
• Local variable declaration freedom
• {} Blocks
• Postfix/Prefix increment/decrement operators (++ and --)
• Using assignments as expressions: x = 5 + (y = 5); results in x being assigned the value of 10
• for and for-each loops
• Initializer (static) blocks

It also redefines some Galaxy constructs to make them more compatible with Andromeda style:

• Forward declarations are no longer necessary (and discouraged)
• The private keyword replaces the static keyword as a visibility modifier (use of the latter is possible, but discouraged)
• Struct declarations no longer have to end with a semicolon
• Reflexive programming using string literals to reference functions is discouraged. The .name field should be used instead to access a function/method's name.

Polymorphism

Andromeda currently only supports inheritance polymorphism. Interface polymorphism is a major planned feature to be added at a later date. Under inheritance polymorphism, classes are allowed to extend other classes to declare what is known in computer programming as a is-a relationship. A class may extend at most one other class; multiple inheritance is not allowed. When class A extends class B, A becomes the subclass (also known as derived or child class) of B, which itself becomes the superclass (also known as base or parent class) of A. A subclass inherits all non-private members of its superclass. Subclasses also have the ability to override, or redefine, non-final inherited instance methods.

Polymorphism arises from the ability to treat objects of subclasses as if they were objects of the superclass type. Another way of saying this is that Andromeda's type system conforms to Liskov's substitution principle, which stated informally is:

If S is a subtype [subclass] of T, then S may be used anywhere T is needed without adverse effect.

Because subclasses can override inherited methods, Andromeda resolves all method calls dynamically. That is, the version of the method that is called is the version belonging to the actual type of the object on which it was called, not on the type of the variable from which the object was referenced. For example, if a call to foo() is made to an object of type B, the subclass, referenced by a variable of type A, the superclass, it is B's version of foo() that will be called.

While true polymorphism is reserved for classes only, a limited form is available to native types as well through the use of type extensions. Type extensions are an expansion of the typedef concept from Galaxy. There are two forms of type extensions: hierarchal and disjoint. Only the former allows for polymorphism. Hierarchal type extensions allow the programmer to declare his own types that extend native types or other type extensions. The same is-a relationship that applies to class inheritance applies here to hierarchal type extensions. Also like class inheritance, subtypes of type extensions may be treated as if they were the supertype. However, method calls to type extensions are resolved statically. That is, the version of the method that is called is the version belonging to the type of the variable from which the call was made.

The second kind of type extension - disjoint - does not allow for any polymorphism. It may only be used to extend native types and not other type extensions. Moreover, the subtype may not be treated as an instance of the supertype. Disjoint type extensions are meant to encapsulate rather than truly extend in a polymorphic sense native types. Therefore, they are usually used to define constructs that can be modeled or represented by a native type, but does not share any behavior with that native type.

Generics

Andromeda supports generic programming with the implementation of generic types. Any class may be declared to be generic by postfixing angled brackets (<>) containing an arbitrary number of type parameters to the class's name in its declaration. Only classes may be generic; unlike in C++, functions cannot be made generic. Two examples of generic class declarations are:

public class LinkedList<T> {
    //...
}

public class TreeMap<K,V> {
    //...
}

LinkedList is a generic type with one type parameter T and TreeMap is a generic type with two type parameters K and V. Generic classes must be parameterized upon instantiation. That is, each parameter must be specified with a type. This can be either a concrete type, another generic type, or even another type parameter (the last two are only valid if the instantiation itself occurs in a generic class). Unlike Java, Andromeda does not allow the instantiation of raw generic objects - objects of generic types that have not been parameterized. Currently, Andromeda allows classes as well as native types that can be interchanged with int to parameterize generics. Wrapper classes must be used to parameterize generics with other native types (such as unit).

Aside from the restrictions described above, generic types are treated as if they were any other type. Generic classes may be extended by concrete or generic classes and vice versa. The Andromeda type system regards the same generic type with different parameterizations (LinkedList<Integer> vs. LinkedList<Fixed>) as different types, so they cannot be used interchangeably. While Andromeda allows inheritance polymorphism with respect to the generic types themselves, it does not allow it respect to the parameters. In other words, assigning a Derived<A> to a variable of type Base<A> is allowed, but assigning a A<Derived> to a variable of type A<Base> is not.

When working with type parameters, no information about the type that eventually will be used in place of the parameter can be determined from the parameter itself. This is because Andromeda uses a strictly nominative type system wherein information about types is contained within the their names. Since parameters are not actual type names but instead only placeholders, they impart no information. A consequence of this is that one may not call any methods on objects whose type is only described by a type parameter or use them where a non-parameter type is expected (e.g. method arguments or return values) without explicit casts. This also renders illegal the invocation of the new or delete operators on objects of a parameter type.

Links

• Andromeda Standard Library
• Andromeda Language Specification
• Installation and Usage Guide
• Download (Resource Database)

Libraries

• User Interface
• Andromeda Standard Library (astdlib)
  • Source Code
  • Talk