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 |
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,
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 |
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. |
Semantics | Home | Copyright 2000-2001 Paul Cantrell |