Re: Query.setRefreshingObjects(boolean)

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon May 05 2008 - 16:47:14 EDT

  • Next message: Brian Nelson: "Re: Custom configuration class ignored in 3.0 snapshot"

    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 : Mon May 05 2008 - 16:47:50 EDT