[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[imp-dev] Re: Proposal for change to ITokenColorer interface
|
Hi Bob,
I like little API changes when they improve things. This one is very much appreciated.
Cheers,
Jurgen
On Tue, Mar 17, 2009 at 3:05 AM, Norman H Cohen
<ncohen@xxxxxxxxxx> wrote:
Our project uses a default implementation--
public IRegion calculateDamageExtent(IRegion
seed) {
return currentColorer.calculateDamageExtent(seed);
}
--so we would just add a formal parameter
to fix the compiler error that results when we upgrade to the next IMP
version, and go on about our business.
FWIW, the LPG code bundled with the
latest IMP release on eclipse.org also broke the API. I don't remember
the details, but some method that had been in an LPG interface was removed
from that interface, but retained in the LPG class implementing the interface.
As a result, I had to insert a few casts from the interface type to the
class type to make calls on that method compile again. I have no problem
with a few small changes like this when it comes as part of an upgrade
to a new version.
------------------------------------------------------------------------------------
Norman Cohen
Sensor and Actuator Solutions
IBM T.J. Watson Research Center, Hawthorne, NY
+1.914.784-7536
http://www.research.ibm.com/people/n/ncohen/
| From:
| |
| To:
| |
| Cc:
| imp-dev <imp-dev@xxxxxxxxxxx>,
Norman H Cohen/Watson/IBM@IBMUS, Andy Frenkiel/Watson/IBM@IBMUS, Jason
C Garcowski/Raleigh/IBM@IBMUS
|
| Date:
| 03/16/09 07:09 PM
|
| 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)
