[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [imp-dev] Re: Proposal for change to ITokenColorer interface
|
yes, we did a workaround and fixing this right would be
good
Hi Bob,
I think Andy Crapo at GE Research was interested in
having calculateDamageExtent(IRegion seed) return an actual calculated value,
and I think I helped him work out a somewhat convoluted way to get the effect
that he wanted (although I can't find any record of that now).
Anyway, if the interface is fundamentally
broken (which it evidently is) then breaking it a second time to fix it is
probably justified. This doesn't seem like the sort of change where the
impact would justify an extension of the original interface. It seems
pretty integral, and at worst it should cause a minor compilation error but
not prevent anyone's custom implementation from working.
Have you posted the question on the
newsgroup?
Regards,
Stan
Stan Sutton, Ph. D.
IBM T. J. Watson Research
Center
19 Skyline Drive, Hawthorne, NY 10532 USA
telephone:
1-914-784-7316, FAX: 1-914-784-7455, T/L 863
e-mail:
suttons@xxxxxxxxxx, Stan Sutton/Watson/IBM@IBMUS
| "Robert M. Fuhrer"
<rfuhrer@xxxxxxxxxxxxxx>
03/16/2009 07:09 PM
|
|
To
| Jurgen Vinju
<jurgen.vinju@xxxxxx>, Stan Sutton/Watson/IBM@IBMUS,
Philippe Charles <pgcharles@xxxxxxxxxxx>
|
|
cc
| imp-dev
<imp-dev@xxxxxxxxxxx>, Norman H Cohen/Watson/IBM@IBMUS, Andy
Frenkiel/Watson/IBM@IBMUS, Jason C
Garcowski/Raleigh/IBM@IBMUS
|
|
Subject
| Proposal for change to
ITokenColorer interface |
|
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)
