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.