
		  WHY TOM IS BETTER THAN ANYTHING ELSE

	      Pieter J. Schoenmakers <tiggr@ics.ele.tue.nl>

				 *DRAFT*

This file explains, as the title suggests, why my favourite programming
language is better than your favourite programming language.  The setup is
similar to the presidential elections in the united states: I will say
anything to put your programming language down in the mud (where it
belongs, obviously).  The main reason for this approach is that the
comparisons touch your knowledge of your favourite language.  [Note 1]

Comparisons

 - It doesn't suffer the bloated featurism of C++.  (This is here to live
   up to the promise in the preceding paragraph, even though it is true
   :-)

 - The programmer of a base class can not restrict the way in which a
   subclass can override methods: there is no such thing as a non-virtual
   member function.

 - Static binding of function calls or, even worse, inlining functions is
   impossible.  Of course you can moan about the speed penalty, but if it
   is in the order of 10% (which it is in TOM), then for most applications
   the flexibility offered by this is much more important than the
   execution speed which will double in 1.5 year's time anyway.  The 10%
   will not make you sell less copies; it might just save you development
   time (and cost), so you can put out the product earlier and it could
   make you sell more copies.

 - All objects are allocated from the garbage collected heap.  This is
   where Java (as a `modern' `popular' example) got it right and C++ and
   Objective-C got it all wrong.  Especially C++, with objects allocated
   from the stack, or contained in other objects.

   And don't complain about how much time garbage collection takes; your
   time fixing allocation problems is much more expensive (here is that
   10% again, though I'm not sure if 10 is the right number; it is
   probably less).

 - The limit on the number of values which can be returned from a method
   is not 1 as in most programming languages; and it is neither optional
   nor special as in Common Lisp.  [Example 1]

 - There is no distinction between interfaces and classes as in Java.

 - There is no distinction between protocols and objects as in
   Objective-C, where, for starters, one can not declare a class object to
   conform to some protocol.

 - TOM has multiple inheritance.  Unlike C++, private inheritance does not
   exist, since that is just a contamination of the `is a' and `part of'
   hierarchies [Note 2].  It also is more clean than multiply-inheriting
   protocols in Objective-C and interfaces in Java with their single
   inheritance class hierarchy; the two concepts are merged in TOM.

 - A binary distributed library comes with enough information for the
   binary distribution not to be an issue.  This in contrast to Eiffel
   where availability of only the short form of a library's interface
   limits the inheritance possibilities defined for the language.  And the
   possibility of distributing the `encrypted long form' is hilarious, to
   say the least.

Notes

 1 Naturally, I don't mind you coming down hard on TOM's bad spots.  It
   might even create an environment in which to enhance TOM.  You know,
   add more features to it so that it can become more like C++!

 2 An object is an object is an object, and not part of one.  Inheritance
   means the behaviour offered by the instances of the superclass is also
   offered by instances of the inheriting subclass, possibly aided in
   offering its functionality by the (also inherited) state information.
   Private inheritance of a class is a hack replacement for a normal
   instance variable with the type of that class; the advantage of the
   hack being direct access to the member variables and the implicit
   relation between the inherited object and the inheriting object (but
   only as far as the virtualness of the inherited methods allows).

Examples

 1 Consider the following method declaration

	(int, int) divmod (int, int) (a, b);

   which declares `divmod', accepting two integers (`a' and `b'), and
   returning two (nameless) integers.  According to the documentation
   accompanying every (and thus also this) method, `divmod' returns the
   integer value of `a / b' and the integer `a % b'.  Thus, the result
   of the expression

	int a, b;

	(a, b) = divmod (5, 2)

   is that `a' is 2, and `b' is 1.  If the only the modulo value is of
   interest, the assignment to the division part can be omitted, as in the
   following expression:

	int a;

	(, a) = divmod (5, 2)
