I have a Location class which represents a location somewhere in a stream. (The class isn't coupled to any specific stream.) The location information will be used to match tokens to location in the input in my parser, to allow for nicer error reporting to the user.
I want to add location tracking to a TextReader instance. This way, while reading tokens, I can grab the location (which is updated by the TextReader as data is read) and give it to the token during the tokenization process.
I am looking for a good approach on accomplishing this goal. I have come up with several designs.
Manual location tracking
Every time I need to read from the TextReader, I call AdvanceString on the Location object of the tokenizer with the data read.
Advantages
Very simple.
No class bloat.
No need to rewrite the TextReader methods.
Disadvantages
Couples location tracking logic to tokenization process.
Easy to forget to track something (though unit testing helps with this).
Bloats existing code.
Plain TextReader wrapper
Create a LocatedTextReaderWrapper class which surrounds each method call, tracking a Location property. Example:
public class LocatedTextReaderWrapper : TextReader {
private TextReader source;
public Location Location {
get;
set;
}
public LocatedTextReaderWrapper(TextReader source) :
this(source, new Location()) {
}
public LocatedTextReaderWrapper(TextReader source, Location location) {
this.Location = location;
this.source = source;
}
public override int Read(char[] buffer, int index, int count) {
int ret = this.source.Read(buffer, index, count);
if(ret >= 0) {
this.location.AdvanceString(string.Concat(buffer.Skip(index).Take(count)));
}
return ret;
}
// etc.
}
Advantages
Tokenization doesn't know about Location tracking.
Disadvantages
User needs to create and dispose a LocatedTextReaderWrapper instance, in addition to their TextReader instance.
Doesn't allow different types of tracking or different location trackers to be added without layers of wrappers.
Event-based TextReader wrapper
Like LocatedTextReaderWrapper, but decouples it from the Location object raising an event whenever data is read.
Advantages
Can be reused for other types of tracking.
Tokenization doesn't know about Location tracking or other tracking.
Can have multiple, independent Location objects (or other methods of tracking) tracking at once.
Disadvantages
Requires boilerplate code to enable location tracking.
User needs to create and dispose the wrapper instance, in addition to their TextReader instance.
Aspect-orientated approach
Use AOP to perform like the event-based wrapper approach.
Advantages
Can be reused for other types of tracking.
Tokenization doesn't know about Location tracking or other tracking.
No need to rewrite the TextReader methods.
Disadvantages
Requires external dependencies, which I want to avoid.
I am looking for the best approach in my situation. I would like to:
Not bloat the tokenizer methods with location tracking.
Not require heavy initialization in user code.
Not have any/much boilerplate/duplicated code.
(Perhaps) not couple the TextReader with the Location class.
Any insight into this problem and possible solutions or adjustments are welcome. Thanks!
(For those who want a specific question: What is the best way to wrap the functionality of a TextReader?)
I have implemented the "Plain TextReader wrapper" and "Event-based TextReader wrapper" approaches and am displeased with both, for reasons mentioned in their disadvantages.
