Hi All,
It's been suggested that we change the ITokenColorer interface in a
backwardly-
incompatible way, but in a way that corrects what I believe was an
obvious
oversight in the interface's design.
Namely, ITokenColorer.calculateDamageRegion(), as presently
defined, is
impossible to implement sanely, since it doesn't receive any
information
it could use to reason about the source text.
The current signature is:
IRegion
calculateDamageExtent(IRegion seed);
Unfortunately, although getColoring() does get passed the
IParseController,
that method would typically be called after calculateDamageExtent(),
for
obvious reasons, so an implementation can't simply cache the
IParseController passed in to that method.
(In fact, all known implementations simply return the region passed
in.
This is now, by the way, the behavior of the implementation provided
by
the recently-upgraded class TokenColorerBase, which didn't used to
implement calculateDamageExtent() at all.)
So, I propose that we change calculateDamageExtent() thusly:
IRegion
calculateDamageExtent(IRegion seed, IParseController ctlr);
The motivation for passing the IParseController to this method is the
same
as that for getColoring(): IParseControllers typically give access
to the token
stream, the character stream, and even the AST (if that proves
useful).
That said, this *would* be a breaking API change, so I'd appreciate
hearing
from anyone with a stake in the outcome.
Comments?
--
Cheers,
--
Bob
--------------------------------
Robert M. Fuhrer
Research Staff
Member
Programming Technologies Dept.
IBM T.J. Watson Research
Center
IMP Team Lead (
http://www.eclipse.org/imp)
X10:
Productivity for High-Performance Parallel Programming (
http://x10-lang.org)