| [imp-dev] 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) |