Eidola: Comparison with Java and C++

Comparison with Java and C++

Semantics | Home

For those of you who know Java or C++, this page will give you an idea of some of the subtle and not-so-subtle features of Eidola. It's not a complete diff -- it just highlights some of the salient features of Eidola. It would be great to include Smalltalk in this comparison as well, but I don't know it well enough. Any volunteers? Other languages you think would be illuminating?

General Differences

Representation independence: The most obvious difference -- C++ and Java are both traditional textual languages, and Eidola is...what it is!
Pure object orientation: Like Java, Eidola takes a fairly strict object-oriented viewpoint. However, Eidola allows functions and variables to be members of packages as well as classes, much like C++ namespace globals. This has no direct analogy in Java, which treats the class as its fundamental storage unit for code, and allows only classes to be members of packages.
Reference types and garbage collection: Like Java, all variables refer to objects by reference, and objects are garbage collected. There is no analogy in Eidola to C++'s distinction between T, T*, and T&. (The semantics don't deal with this yet, but they will.)

Classes, Members and Inheritance

Explicit member inheritance: Java and C++ both automatically inherit members of a superclass when the subclass does not explicitly override them. In a text-based language, this is quite reasonable -- it saves a good many keystrokes! In Eidola, however, a subclass explicitly inherits or overrides every member of its superclasses. This is a result of Eidola's view of classes as a signature-based type system. It not only makes the notion of a signature much tighter and cleaner, but solves the major problems of multiple inheritance.
Multiple inheritance: Unlike Java, Eidola allows a class to have multiple parents. The manner in which Eidola does this, however, is substantially different from C++, which tries to make multiple inheritance a means of both specializing and agglomerating types, and thus draws a complicating distinction between virtual and non-virtual superclasses. Eidola's multiple inheritance is much more akin to how a class implements multiple interfaces in Java -- the class simply needs to have a set of methods to satisfy the signature of each interface, and one member can satisfy multiple interfaces. Eidola's explicit inheritance removes the need for Java's distinction between classes and interfaces by allowing a subclass to explicity pull code from a superclass, even when name overlaps might create an ambiguity.
Virtual members: C++ requires the programmer to explicitly declare a member function "virtual" to make runtime type determine what gets called. Like Java, all member functions in Eidola are virtual. Unlike the others, however, all members in Eidola are virtual, including member classes. So in Eidola, new someObject.InnerClass() uses the runtime type of someObject to determine whether InnerClass or a specialization gets instantiated. (The semantics don't completely deal with this yet, but they will.)
Signature specialization: In both Java and C++, the signature of a member in a subclass must be identical to the signature in the superclass. Eidola allows a subclass to specialize types when it overrides a member. For example, if StringList extends List, then StringList.add(String item) can legally override List.add(Object item). Because of that wily virtual method invocation, this produces the possibility of a runtime type exception for a parameter passing which does not exist in Java or C++. It removes, however, the need for the awkward practice of immediately downcasting function parameters (which produces the same runtime type exceptions in Java, and much worse things in C++), and places this construct in the signature of the class, where it belongs.

Functions

Multiple function outputs: Eidola treats a function's outputs much as Java and C++ treat its inputs: both sorts of parameters have names, and behave like local variables. On function entry, the inputs have values which came from the caller, and on exit, the outputs have values which go back to the caller. This allows some of the same good things that pass-by-reference allows in C++, but in a cleaner way which makes parameters' roles clearer to the caller, and doesn't thwart garbage collection.
Parameter names in signatures: Eidola treats the names of the parameters of a function as part of its signature, so when you override a function in a subclass, the parameter names have to remain the same.

Missing Features

Eidola does not include the following features yet: constants and enumerations; constructors and destructors/finalizers; protected, static, and final members; primitive types; function and variable references; friends.
It's not clear that all of these are necessary, or even good ideas; however, each has its merits, and though Eidola may not include them all, it will address the problems that each solves in some creative way.