ANNOUNCEMENT: TOM, version 0.01 
Author Message
 ANNOUNCEMENT: TOM, version 0.01

The first release of `tom' is available.  TOM is an object-oriented
programming language.  It was inspired by Objective-C, but it does not
suffer a `C' heritage and its `Objective' part is richer and more
consistent.  For the same reason, tom is also a nicer language than Java.

This first release has been tested on hppa-hpux and m68k-next machines.
It also runs on i*86-linux and i*86-freebsd.  Porting to a different
machine is not difficult, and you are encouraged to do so.

Below is a list of things addressed by tom.  For more information, see
" http://www.*-*-*.com/ :8080/".  --Tiggr

   Extensibility
          In Smalltalk and Objective-C methods can be added to an already
          existing class, but instance variables can not. In C++, a class
          is defined by its one and only definition.

          In tom, a class need not be defined by one monolithic
          definition: its definition can be split into multiple parts,
          called extensions. An extension can add instance and class
          variables; it can declare new superclasses from which to
          inherit; and it can add, or replace, methods.

   Usability
          With tom, the semantics of the language do not change with the
          availability of sources. Put more strongly, the possibilities
          of the language are not restricted in any way if sources are
          not available.

          This in contrast to, for example, Eiffel, where the
          availability of only the short form of a class severly hampers
          the possibilities of subclassing.

          As another example, given a C++ library of which one wants to
          replace a class by a different one. In that case, the member
          variables must remain identical if referred to from within one
          of the other objects in the library. The same is true for
          virtual methods if invoked from the other objects. If any of
          the member functions of the class to be replaced is inlined in
          the other objects, the possibility of successfully completing
          this venture within the original goals is further reduced.

   Uniformity
          C++ provides signatures, Java calls them interfaces, and
          Objective-C refers to them as protocols. Apart from some of the
          more obscure problems, such as an Objective-C class object not
          being able to adhere to a protocol, these constructs are
          orthogonal to the normal class hierarchy. In Java and
          Objective-C, they provide a means for multiple inheritance of
          behaviour declaration; in C++ it is an attempt to cover some of
          its many deficiencies.

          In tom, the functionality of protocols (and signatures and
          interfaces) is simply provided by the class hierarchy itself;
          this is implied by: multiple inheritance, deferred methods,
          extensibility, a strict distinction between instances and
          classes, and the fact that instances without any instance
          variables can be inherited by both classes and instances.

   Static
          TOM is strongly type checked at compile time; various (builtin)
          basic types and the (user defined) object classes are
          discerned. Methods are overloaded on both the argument types
          and the types of the return values.

          The class of the receiver of a message (or call it the object
          of which a member function is invoked) is used to decide the
          availability of the method, and the types of the values
          accepted and returned. However, the method actually invoked is
          not statically bound: all methods are dynamically bound. In the
          context of extensibility and usability it also implies that all
          object references have the same type.

   Dynamic
          At runtime tom provides full typing information on objects,
          their instance and class variables, and arguments to and return
          value from methods. All methods are dynamically bound. Methods
          are provided to read and set instance and class variables given
          their name; to retrieve an object's class; to query a class for
          its position in the inheritance hierarchy; to send an object a
          message of which the selector need not be known at compile time
          (a bit like function pointers in C++, but being dynamically
          bound much more flexible; more like perform in SmallTalk and
          Objective-C, but without restrictions on the types and number
          of arguments).

   Storage Management  
          All objects are allocated from the garbage collected heap. This
          implies that it is impossible to have problems with dangling
          references, previously valid pointers suddenly pointing into  
          the void, memory leaks, etc.

          In tom, an object can not be a part of an entity of which the
          lifetime is unrelated to, and possibly shorter than, the
          lifetime of the object. This containment rule dictates that  
          objects can not be allocated from the stack and they can not be
          part of another object. (Arrays seem a valid counterexample,
          but in tom object arrays hold references, never the actual
          objects.)

   Return Values
          In most languages, there is an arbitrary limit on the number of
          values a method or function can return without reverting to
          tricks. This limit is 1, and pointer arguments are needed to  
          `return' more than one value, or the return values need to be
          packed into an aggregate entity which can then be returned as
          the single return value. In Common Lisp, multiple-valued
          returns are possible, but they are `special'.

          TOM imposes no limit on the number of values that can be
          returned from a method.

   Exceptions
          In most languages (C++, Java, NeXT's Objective-C libraries, to
          name but a few), an exception handler is executed in its own
          context instead of the context of the exception raiser,  
          implying that it is impossible for the handler to direct the
          actions of the condition raiser---the stack has already been
          unwound and nothing can be done about that.

          The tom exception mechanism is modeled after Common Lisp
          conditions. A tom condition can be signaled; if none of the
          condition handlers is interested in handling this condition,
          execution continues in the context of the condition signaler,
          as if the signal were a normal method invocation. A condition
          handler can direct the condition signaler by setting the value
          to be returned from the signal invocation. It can also decide
          to perform a non-local exit, the equivalent of a C longjmp.  

          It is of course possible for a method not to be able to
          continue execution after a condition. In this case it can force
          the condition to be handled, by raising it instead of
          signaling. Failure to handle a raised condition through a
          non-local exit results in an abnormal program termination.



Tue, 22 Dec 1998 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Rubum-tools version 0.01

2. Announce: VOTE version 0.01

3. 0.01 dragons slain

4. strongForth 0.01 available

5. ANN: TOGA (Timetables Optimised with Genetic Algorithms) v 0.01

6. PyStemmer 0.01 available

7. ANNOUNCE: SCons 0.01 now available

8. TMDA 0.01 - A qmail-based anti-SPAM system

9. TreeWidget 0.01

10. PyKstat 0.01 - Solaris kstat(3k) access

11. mpegCam 0.01

12. pmpp 0.01 - HTML Pre-Processor

 

 
Powered by phpBB® Forum Software