-*- 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 .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 .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 = 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 = 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
** 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 $