Of course, how could I forget!
Regardless, what's the point of providing API that compiles and then
ambiguously breaks?
-----Original Message-----
From: Mike Kienenberger [mailto:mkienen..mail.com]
Sent: Monday, May 05, 2008 6:21 PM
To: use..ayenne.apache.org
Subject: Re: Query.setRefreshingObjects(boolean)
You don't have to declare the throw clause if it's a RuntimeException.
The method signature doesn't have to change.
On 5/5/08, Scott Anderson <sanderso..irvana.com> wrote:
> > I don't see
> > much benefit to providing a binary-compatible method API that does
> > nothing.
>
> ...
>
> > Another possibility is to..eprecate the method and have it
> > unconditionally throw a RuntimeException telling the developer to
> > rewrite using query cache options.
>
>
> Adding a Throws clause to the method would change its signature,
thereby
> breaking the binary compatibility of the method. It's a good idea,
but
> it won't solve that problem. :)
>
> Regards,
>
> Scott
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienen..mail.com]
> Sent: Monday, May 05, 2008 5:01 PM
> To: use..ayenne.apache.org
> Subject: Re: Query.setRefreshingObjects(boolean)
>
> Just to reiterate, I see no problem with axing it entirely. I don't
> think we have to nicely deprecate everything since we're now in 3.0
> and it's marked unstable.
>
> However, we should make the need for change obvious. I don't see
> much benefit to providing a binary-compatible method API that does
> nothing. As an end-user, I want to see things either work as they
> always worked, or be given a clear unavoidable indication that work
is
> required on my part to fix it.
>
> Another possibility is to..eprecate the method and have it
> unconditionally throw a RuntimeException telling the developer to
> rewrite using query cache options.
>
> On 5/5/08, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > Actually I was going to do the opposite, but since we've set the
> backwards
> > compatibility bar for ourselves pretty high in the past, I guess I
am
> > persuaded to go with deprecated-but-don't-cripple approach. I guess
> that
> > means also putting a deprecation note in the Modeler next to
refresh
> > checkbox.
> >
> > Andrus
> >
> >
> > On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
> >
> >
> > > I'd like to second the opinion that deprecated still works (until
> > > removed), but is discouraged from use. I believe that is what
> Andrus
> > > intends, though, given previous API changes.
> > >
> > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger
> <mkienen..mail.com>
> > wrote:
> > >
> > > > I guess my problem is that to me..eprecate means "it still
works
> like
> > > > it used to, but it won't work in a future version and it's time
> for
> > > > you to change your code", but that's not what's going to happen
> here.
> > > >
> > > > That's why if we're not really..eprecating it but crippling
it,
> then
> > > > I'd recommend removing it. Giving end-users the false-hope
that
> > > > things are working as usual isn't very nice.
> > > >
> > > > You know the details of this particular situation better than I
> do,
> > > > though. If you don't think silently doing nothing will affect
> > > > expected program behavior, go for it.
> > > >
> > > >
> > > >
> > > > On 5/5/08, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
> > > > >
> > > > >
> > > > >
> > > > > > To me, that sounded like you were going to change the
behavior
> > rather
> > > > > > than just mark the method as..eprecated.
> > > > > >
> > > > > >
> > > > >
> > > > > I was planning to do both. Although we may decide to be
gentle
> about
> > it and
> > > > > deprecate the method, but preserve the functionality (which
will
> put a
> > bit
> > > > > of extra maintenance burden on us).
> > > > >
> > > > > I am leaning towards the first option (deprecate and stop
> invoking),
> > > > > especially since the nature of the change results in enhanced
> data
> > > > > consistency, so there won't be any unpleasant surprises.
> > > > >
> > > > > Andrus
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
This archive was generated by hypermail 2.0.0 : Tue May 06 2008 - 12:45:39 EDT