NoopDelegate is final?

[Mike Kienenberger <mk...@gmail.com>]

I noticed that Noop[DataContext]Delegate is final.   Wouldn't it make
more sense to have a default DataContextDelegate that could be
extended only for the methods needed?

Maybe rename NoopDelegate to DefaultDataContextDelegate and make it non-final.

Re: NoopDelegate is final?

[Andrus Adamchik <an...@objectstyle.org>]

> 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 <an...@objectstyle.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.
>

Re: NoopDelegate is final?

[Mike Kienenberger <mk...@gmail.com>]

On 8/29/06, Andrus Adamchik <an...@objectstyle.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.

Re: NoopDelegate is final?

[Andrus Adamchik <an...@objectstyle.org>]

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.

Andrus


On Aug 27, 2006, at 12:09 AM, Mike Kienenberger wrote:

> I noticed that Noop[DataContext]Delegate is final.   Wouldn't it make
> more sense to have a default DataContextDelegate that could be
> extended only for the methods needed?
>
> Maybe rename NoopDelegate to DefaultDataContextDelegate and make it  
> non-final.
>