$Id: TODO,v 1.63 1999/06/05 20:10:53 tiggr Exp $

CURRENT VERSION: 1.0 (June 6, 1999)

BEFORE NEXT RELEASE

 no known bugs

AFTER NEXT RELEASE

 no known bugs

TOM (LANGUAGE)

 * Think about switch, enum and packed (for bitfields and booleans).  

 * How about encapsulation at the level of a unit, i.e. somewhere between
   public and protected.

 * Encapsulation at the level of the sender, i.e. self v. not self.
   [Sun May 4 23:59:47 1997, tiggr@tricky.es.ele.tue.nl]

 * It must be possible to inherit the interface of a class, without
   inheriting the state or the implementation of the behaviour.  Possibly,
   only methods explicitly declared `public' (as opposed to declared
   without protection directive) could be included in said interface.

 * Think about adding handling dynamic typed arguments in TOM.  Its use
   would resemble `va_arg' in C, but without the unnecessary va_list and
   type-to-retrieve, and including checking of the type retrieved with the
   type expected.  [Wed Aug 21 13:03:41 1996, tiggr@cobra.es.ele.tue.nl]

 * Think about tuple arguments more resembling the C arguments prototype.
   [Fri Aug 23 11:36:50 1996, tiggr@cobra.es.ele.tue.nl]

 * As very syntactic sugar, it would be nice to declare the following
   object variable: `public (Mapped) MutableDictionary x' to mean that for
   the declaring object, `x' is a MutableDictionary, and the accessor
   method implied by the `public' returns something of the type `Mapped'.
   [Fri Aug 30 17:36:39 1996, tiggr@cobra.es.ele.tue.nl]

 * Similarly, a `private (Mapped) MutableDictionary x' would be a
   MutableDictionary in the declaring class, and a Mapped (unmutable)
   collection in subclasses.  [Mon Sep 2 13:00:56 1996,
   tiggr@cobra.es.ele.tue.nl]

 * Conditional compilation is not unnecessary...  [Sat Oct 26 17:21:23
   1996, tiggr@jaguar.ics.ele.tue.nl]

 * Having a load method just to initialize class variables should not be
   necessary.  [Wed Oct 30 13:32:15 1996, tiggr@jaguar.ics.ele.tue.nl]

 * Allow the last method name part to be argumentless, just like currently
   a method with only one name part can be argumentless (i.e. its last and
   only namepart is argumentless).  This would increase the usefulness of
   curried invocations.  [Mon Nov 11 16:41:37 1996,
   tiggr@jaguar.ics.ele.tue.nl]

 * What about `dynamic inheritance'?  Suppose this instance of the
   OutputStream subclass X does not want to have itself be flushed upon
   invocation of the `nl' method, thus is adds (with some higher priority)
   to its inherited superclasses the class that implements the `nl' method
   without flushing...  [Tue Dec 10 14:32:38 1996,
   tiggr@jaguar.ics.ele.tue.nl]

 * A class can be `fixed', meaning that extensions are not allowed to
   introduce new non-static state, either directly or through inheritance.
   For example, a ByteString can become a CaseInsensitiveByteString, if
   the latter can be made fixed, since when fixed it is guaranteed that
   its state will always be identical to the state of the ByteString.
   [Wed Jun 18 14:42:08 1997, tiggr@cobra.ics.ele.tue.nl]

tomc (COMPILER)

 * Check for non-colliding method signatures when adding super classes to
   a class.

 * A return in a bind condition-handler does not actually return from the
   method, but from the handler.

 * A return within an bind, catch, or unwind does not unregister, though
   it should.  Within an unwind, it should also execute the unwind code.
   [Sun Sep 1 21:10:22 1996, tiggr@tricky.es.ele.tue.nl]

 * Change the calling interface, so that a C struct return is used instead
   of extra pointer arguments at the end, for a multi-valued return.  This
   will be faster than the current setup.  [Sun Sep 8 16:56:20 1996,
   tiggr@tom.es.ele.tue.nl]

   With these separate pointers, GCC is able to more smartly allocate
   stack space to variables, since there is no need to retrieve everything
   from this temporary struct.  [Fri Nov 8 10:35:09 1996,
   tiggr@jaguar.ics.ele.tue.nl]

   Especially if GCC can spot them as output-only parameters?  [Sat Dec 14
   23:39:15 1996, tiggr@jaguar.ics.ele.tue.nl]

   Maybe GCC can spot them if their address is passed and they have not
   been written yet.  [Wed Dec 25 23:00:47 1996,
   tiggr@tricky.es.ele.tue.nl]

 * Check for loops in the inheritance graph and in a posing specification.
   Gently, instead of dumping core.  [Thu Apr 10 15:07:31 1997,
   tiggr@cobra.ics.ele.tue.nl]

tomr (RESOLVER)

 * With a flag to the resolver indicating that no dynamic loading will be
   performed, some meta structures can be removed from the executable.
   These are meta's which never have direct instances, i.e. those with at
   least one deferred method.

 * Check (or prove) that all kinds of resolving work (static, global, etc).

 * Extension offset tables (especially the all-zero ones, and those
   directly inheriting from State) can be shared.  [Wed Nov 6 01:25:34
   1996, tiggr@jaguar.ics.ele.tue.nl]

 * It seems sharing string constants doesn't do too much (for the current
   tag/test, there are 145 string constants of which only 122 are unique).
   [Wed Nov 6 01:41:05 1996, tiggr@jaguar.ics.ele.tue.nl]

GI (INTERFACE GENERATOR)

 * Rewrite in TOM.

TRT (RUNTIME)

 * Add functions with the names of those functions used by Objective-C
   code, with the obvious semantics (i.e. seamless integration of TOM
   and Objective-C code).  [Sat Aug 31 14:49:40 MET DST 1996,
   tiggr@tom.es.ele.tue.nl]

 * Implement signal conditions, handlers and the like.  [Thu Sep 26
   13:22:39 1996, tiggr@tom.es.ele.tue.nl]

 * Make garbage collection not assert the runtime lock, and the same for
   [class (State) alloc].  Other threads should be able to continue
   running while one thread is doing garbage collection.  [Sun Sep 29
   14:59:17 1996, tiggr@jaguar.ics.ele.tue.nl]

 * The registers of other threads are not yet marked during a GC run.
   Similarly, the top of stack of the other threads are taken from the
   recorded top of stack of the most recent invocation of [State alloc].
   [Mon Oct 28 17:14:07 1996, tiggr@jaguar.ics.ele.tue.nl]

 * Make the trt low-level hashtable also hash sensibly.  [Thu Apr 17
   18:24:37 1997, tiggr@akebono.ics.ele.tue.nl]

TOM (UNIT)

 * Make sure String and MutableString are able to `natively' handle {byte}
   and {char} types.

 * Add functioning copying methods to other containers in addition to
   Array.  [Sun Sep 22 19:59:03 1996, tiggr@tricky.es.ele.tue.nl]

 * Handle numeric arrays (byte, char, int, and long) more abstractly,
   helped by a class variable for the `elementByteSize'.  [Sun Oct 20
   15:35:47 1996, tiggr@jaguar.ics.ele.tue.nl]

 * Handle Indexed collections more abstractly, to be able to easily make
   Queues for every Array (or, preferable, Indexed) class.  [Sun Oct 20
   15:36:26 1996, tiggr@jaguar.ics.ele.tue.nl]

 * Clean up the ByteString and ByteSubstring mess.  [Fri Nov 1 17:40:38
   1996, tiggr@jaguar.ics.ele.tue.nl]

 * Streams should be extended to have an encoding associated with them.
   [Fri Nov 1 17:40:42 1996, tiggr@jaguar.ics.ele.tue.nl]

TOO (UNIT)

 * Suppose the following method is invoked remotely:

	String echo String arg { = arg; }

   and the ARG is sent over the wire bycopy.  Should the object returned
   from the remote method invocation be the identical object provided as
   an argument?  If so, object uniquing must be shared between encoders
   and decoders.  Currently (shortly, really), sharing is only implemented
   in each separate direction.  Thus, the remote invocation of [foo do
   (my_obj, my_obj)] actually passes only one copy of my_obj.  [Wed Aug 6
   00:48:30 1997, tiggr@tricky.es.ele.tue.nl]
