cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: NoopDelegate is final?
Date Thu, 07 Sep 2006 20:09:07 GMT
> 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 <andrus@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.
>


Mime
View raw message