Re: NoopDelegate is final?

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Sep 07 2006 - 16:09:07 EDT

  • Next message: Mike Kienenberger: "Large code contributions"

    > 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.

    If there are still people who write Java code in vi, this is their
    choice - there is nothing we can do to help them :-) I am trying to
    avoid the clutter, but I don't have strong feelings either way and
    certainly will not veto this change, if you feel that it is useful.

    I guess another reason I wasn't excited about the delegate is that I
    have a hope of making the DataChannel decorator work (should be
    fairly easy; the idea is briefly mentioned in [1]), and I feel that
    would be a superior solution. But then again, the two do not conflict
    with each other.

    Andrus

    [1] http://objectstyle.org/cayenne/lists/cayenne-user/2006/09/0010.html

    On Sep 7, 2006, at 10:52 PM, Mike Kienenberger wrote:
    > 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 - 16:09:30 EDT