On 8/29/06, Andrus Adamchik <andru..bjectstyle.org> 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.
This archive was generated by hypermail 2.0.0 : Thu Sep 07 2006 - 14:52:33 EDT