-*- mode:outline; minor-mode:outl-mouse -*-

* Bugs:

** DJ: multiple inheritance of interfaces

If a class can trace multiple inheritance paths to the same interface,
traversals starting at that interface will visit objects of that
class multiple times.

** compilation process on Windows may hang after running JavaCC

On Windows, sometimes demeterj hangs after running the parsegen module.
Workaround: use the "-eofbug" option.

** "demeterj test" on Windows may hang after running

Sometimes "demeterj test" on Windows hangs after the program finishes
running.  This seems only to happen only when the program needed to be
recompiled, i.e. "demeterj compile" followed by "demeterj test" doesn't
hang.  Workaround: use the "-eofbug" option.

** "demeterj test" on Windows doesn't see EOF

If your program reads input from stdin, and you're on Windows, and you
use "demeterj test", your program will never get EOF on the input
stream.  You'll have to run your program directly, with something like

    java -cp gen\classes;c:\demeterj\demeterj.jar <package>.Main

replacing "c:\demeterj" with wherever you installed DemeterJ.

** interactive use with -noblock doesn't see EOF

If your program reads input from stdin, and you don't specify
TEST_INPUT in your project file, and you're on a platform on which
blocking I/O blocks the process instead of just the thread, and you
use "demeterj -noblock test", your program will never get EOF on the
input stream.  You'll have to run your program directly, with
something like

    java -cp gen\classes;c:\demeterj\demeterj.jar <package>.Main

replacing "c:\demeterj" with wherever you installed DemeterJ.

** can't have two inline adaptive methods with the same name

This causes a name conflict due to the generated traversal name:

    Foo {
      void f(int x) to Bar (FooVisitor1)
      void f(char y) to Baz (FooVisitor2)
    }


This causes a name conflict due to the generated visitor name:

    Foo {
      void f(int x) = t1 { }
      void f(char y) = t2 { }
    }

** adaptive methods can't have array parameters

An adaptive method can't have a parameter of an array type, e.g.

    Foo { void f(int x[]) to Bar { } }

will generate an erroneous visitor

    __Foo_f = <x> int.

** methods can't have final parameters

Final method parameters (added in JDK 1.1) cause parse errors.

** "@)" syntax causes PrintVisitor to choke

If your class dictionary contains "@)" as a syntax string, the
generated PrintVisitor.beh will cause an error when lexing.  A
workaround is to use two strings, "@" ")", or just use Text.

** strategies that go through an abstract class

Things like this don't work correctly:

    Foo = Bar *common* Fred.
    Bar : Baz.
    Baz = .

    Foo { traversal f(V v) { via Bar to Fred; } }

It never gets to the Fred object.

** syntax between optional parts

The generated PrintVisitor won't compile if your CD has something like
the following:

    Foo = [ Bar ";" ] "*" [ Baz ].

It creates two after__bar(Foo foo, Bar dest) methods on PrintVisitor.

** default part names for lowercase types

The default part name is the type converted to lowercase, but this
doesn't work if the type (class or primitive type) is already
lowercase.

** visitor methods on terminal classes

A visitor method on a terminal class (a class that's not defined in
the class dictionary), such as "before int {{ ... }}", will never be
called.  Defining one should produce an error at code generation time.

** globbing problems with edges

"before -> *,*,*" is somewhat broken.  So is "before -> A,*,B".

** multiple visitors with around methods

If you attach multiple visitors to a traversal, and some of them have
around methods and some have before & after methods, the order of
invocation is a little screwy.

** around methods and alternation classes

Around methods on alternation classes won't be called.

** multiple wrappers for the same class

A visitor may not have two wrappers for the same class, e.g.

    before { Foo, Bar } (@ ... @)
    before Foo (@ ... @)

This should be allowed, and they should be called in the order seen in
the .beh file.  A similar problem exists with "before *" and "before Foo".

** abstract visitors need empty wrappers

If you have an abstract visitor:

    Foo = .
    AbstractVisitor : ConcreteVisitor.
    ConcreteVisitor = .

and you have a traversal that uses the abstract visitor:

  Foo { traversal foo(AbstractVisitor v) { to *; } }
  ConcreteVisitor { before Foo (@ ... @) }

The before method for Foo won't be seen.  You have to add:

  AbstractVisitor { before Foo (@ @) }

This should rather be deduced automatically.

** cannot inherit from parameterized classes

This doesn't work:

  Foo = *extends* List(Bar).

** cannot have "deep" parameterization

This doesn't work:

  Foo(X) = Bar(X).

** error reporting sucks

Error messages should have line numbers, and in general be more
informative.

** comment propagation

Comments in .beh files outside Text blocks should be propagated to the
generated .java files.

** DisplayVisitor

The DisplayVisitors that are generated don't do a great job with
repetition classes.

** Weaver modifier order is too strict

The aspect weaver doesn't accept "static public" methods, only "public 
static"; i.e. the visibility declaration must come first.

** generate module doesn't check options correctly

The code generator accepts options like "-grumble" and assumes it's
the same as "-grammar" because it begins with the same three
characters.  It should reject options that aren't prefixes of valid
options.  (The front-end uses matchOption() to do this.)

* Missing features:

** DJ: iterator should support all of ListIterator

The iterator returned by ObjectGraphSlice.asList().iterator()
currently only supports hasNext(), next(), and set(); it should
support all the other methods defined on ListIterator.

** behavior files should allow import statements

You should be able to put an import statement at the top of a behavior 
file, which will be inserted into all the .java files that are
generated from that behavior file.

** Line should allow end-of-line escape

The lexical rule for a Line object should allow a backslash at the end
of the line to indicate that the line continues on the next line.

** project files should be more makefile-like

The project file language should include things like variable
substitution (e.g. $(FOO)) and more complicated rules, or at least
some way to do subdirectories.

** project files should inherit from user-global and site-global files

There should be some way to specify project file settings that are
global to all of a user's projects or all of a site's projects-- maybe 
a .demeter file in $HOME and/or in the directory where Demeter is
installed can specify settings that are inherited by all projects,
e.g. compiler and compiler options.  Local projects files should then
only define things that need to be overridden.

** array parts

A class should be allowed to have array parts, e.g.

    Foo = <x> int[].

** compound strategies

Join (concatenation), merge (union), and intersection.

** named strategies

You should be able to name a strategy and refer to it in a later
strategy expression.

** general way to initialize visitors and compute return value in adaptive methods

Adaptive methods with multiple visitors should allow some way to
initialize the visitors other than the first, as well as compute a
return value from multiple visitors.

** less output

There should be an option to control how many debugging/status
messages demeterj should print, with the default being something less
than what it is currently (probably nothing for a successful run).

** multiple CD files

The user should be able to list multiple .cd files in the project file.

** parsing external classes

There should be a way to specify how an external (terminal) class can
be parsed.

** container classes

The user should be able to make repetition classes use any class for
the container (e.g. Vector), not just a linked list.

** composite visitors

Visitors should be able to add subvisitors to the current traversal.
E.g. AverageVisitor adds SumVisitor and CountVisitor.

** parameterized visitors

Visitors should be able to be parameterized with the classes where
behavior is attached.  E.g. CountVisitor<Basket,Apple>

** extend Java

Add syntax to Java for traversals & visitors.

** subtraversals

Should be able to restrict a visitor to a portion of a traversal.

** structural extension

Visitors should be able to add structure as well as behavior.

** context objects

General context objects (Linda's thesis).

** parallelism

Multiple visitors in parallel on a traversal, or visit aggregates
(repetition object) in parallel.


$Id: BUGS,v 1.32 2003/01/20 13:16:18 dougo Exp $