On 8/29/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
Don't see this as an issue. It is trivial to implement, and my general approach was to keep the amount of public helper code to the minimum.
I see it as an issue :-) It's only trivial to implement if you have an IDE that generates an interface automatically, and even then, for all non-void methods, you have to understand what return values perform a noop. More importantly, it forces the end user to update their application every time someone changes the DataContextDelegate interface. By providing a base noop implementation that people can extend from, they only have to understand (and maintain) the method that they care about. Furthermore, they don't have to make any code changes if we modify the interface (add, delete, or change a method signature) for a delegated method that they do not use. What I consider to be trivial is to change NoopDelegate from a final to a non-final class with a better name. :-) It's the same work for us to maintain NoopDelegate whether or not it's extendable.
