Re: Discussion on Deprecation
> On Mar 17, 2020, at 9:03 AM, John Blum wrote: > > Additionally, it'd be ideal if the deprecated method were then adapted to > delegate to the new approach. This will cut down on the number of required > tests since then you only need a Unit Tests asserting the method performs > the translation/delegating appropriately, unless of course the behavior is > changing too. +1 to delegating
Re: Discussion on Deprecation
Additionally, it'd be ideal if the deprecated method were then adapted to
delegate to the new approach. This will cut down on the number of required
tests since then you only need a Unit Tests asserting the method performs
the translation/delegating appropriately, unless of course the behavior is
changing too.
On Tue, Mar 17, 2020 at 8:57 AM Udo Kohlmeyer wrote:
> I think we are also missing the other side of the coin.
>
> Once we deprecate something and we now need a equivalent test that tests
> the same behavior using the new method/approach. i.e now we have to
> double up on the testing of said deprecated method/feature/class. First
> we have to keep the tests around that use the deprecated and now we need
> the same test for the new. Otherwise we cannot ever be certain that both
> approaches work.
>
> In addition to this, if we don't create both tests, we have to create
> all the tests at the time of removal, otherwise we lose coverage.
>
> --Udo
>
> On 3/16/20 9:27 AM, Joris Melchior wrote:
> > +1 on leaving testing of deprecated functionality in place
> >
> > On Mon, Mar 16, 2020 at 11:50 AM Dan Smith wrote:
> >
> >> +1
> >>
> >> One point though - we do need to leave some tests that specifically test
> >> the deprecated method(s), since we still support the deprecated APIs
> until
> >> we remove them. Everything else should be converted.
> >>
> >> -Dan
> >>
> >> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett
> wrote:
> >>
> >>> Hey Team,
> >>>
> >>> When deprecating a symbol, like class or method, please included a
> >>> reference to the replacement in the java docs. Also please include an
> >>> example of converting from the old API to the new. I am finding many
> many
> >>> places in the source where deprecated code has no hints at all. As many
> >> of
> >>> us don’t take the effort to immediately convert old tests over to the
> new
> >>> APIs the context is lost when someone finally does get around to it.
> For
> >>> public APIs this is extremely important so that users know how to
> migrate
> >>> their code with as few roadblocks as possible.
> >>>
> >>> Here is an example of something that is much better than most of what I
> >> am
> >>> seeing.
> >>>
> >>> /**
> >>> * @deprecated Replaced with something better and safer.
> >>> * Replaced by {@link Bar}.
> >>> */
> >>> @Deprecated
> >>> class Foo {
> >>>/**
> >>> * Do something.
> >>> *
> >>> * @deprecated Replaced with something better.
> >>> * Replaced by {@link Bar#doSomethingBetter()}
> >>> */
> >>>@Deprecated
> >>>public void doSomething() {}
> >>>
> >>>/**
> >>> * Do something.
> >>> *
> >>> * @deprecated Implementation is not safe.
> >>> * Replaced with {@link Bar#doSomethingBetter()} and {@link
> >>> Bar#doSomethingElse()}.
> >>> * Migration example, replace:
> >>> * {@code
> >>> * Foo foo = new Foo();
> >>> * foo.doSomethingAndSomethingElse();
> >>> * }
> >>> * with:
> >>> * {@code
> >>> * Bar bar = Bar();
> >>> * bar.doSomethingBetter();
> >>> * bar.doSomethingElse();
> >>> * }
> >>> */
> >>>@Deprecated
> >>>public void doSomethingAndSomethingElse() {}
> >>> }
> >>>
> >>> class Bar {
> >>>public void doSomethingBetter() {}
> >>>public void doSomethingElse() {}
> >>> }
> >>>
> >>> -Jake
> >>>
> >>>
> >
>
--
-John
Spring Data Team
Re: Discussion on Deprecation
I think we are also missing the other side of the coin.
Once we deprecate something and we now need a equivalent test that tests
the same behavior using the new method/approach. i.e now we have to
double up on the testing of said deprecated method/feature/class. First
we have to keep the tests around that use the deprecated and now we need
the same test for the new. Otherwise we cannot ever be certain that both
approaches work.
In addition to this, if we don't create both tests, we have to create
all the tests at the time of removal, otherwise we lose coverage.
--Udo
On 3/16/20 9:27 AM, Joris Melchior wrote:
+1 on leaving testing of deprecated functionality in place
On Mon, Mar 16, 2020 at 11:50 AM Dan Smith wrote:
+1
One point though - we do need to leave some tests that specifically test
the deprecated method(s), since we still support the deprecated APIs until
we remove them. Everything else should be converted.
-Dan
On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett wrote:
Hey Team,
When deprecating a symbol, like class or method, please included a
reference to the replacement in the java docs. Also please include an
example of converting from the old API to the new. I am finding many many
places in the source where deprecated code has no hints at all. As many
of
us don’t take the effort to immediately convert old tests over to the new
APIs the context is lost when someone finally does get around to it. For
public APIs this is extremely important so that users know how to migrate
their code with as few roadblocks as possible.
Here is an example of something that is much better than most of what I
am
seeing.
/**
* @deprecated Replaced with something better and safer.
* Replaced by {@link Bar}.
*/
@Deprecated
class Foo {
/**
* Do something.
*
* @deprecated Replaced with something better.
* Replaced by {@link Bar#doSomethingBetter()}
*/
@Deprecated
public void doSomething() {}
/**
* Do something.
*
* @deprecated Implementation is not safe.
* Replaced with {@link Bar#doSomethingBetter()} and {@link
Bar#doSomethingElse()}.
* Migration example, replace:
* {@code
* Foo foo = new Foo();
* foo.doSomethingAndSomethingElse();
* }
* with:
* {@code
* Bar bar = Bar();
* bar.doSomethingBetter();
* bar.doSomethingElse();
* }
*/
@Deprecated
public void doSomethingAndSomethingElse() {}
}
class Bar {
public void doSomethingBetter() {}
public void doSomethingElse() {}
}
-Jake
Re: Discussion on Deprecation
> On Mar 16, 2020, at 8:50 AM, Dan Smith wrote: > > +1 > > One point though - we do need to leave some tests that specifically test > the deprecated method(s), since we still support the deprecated APIs until > we remove them. Everything else should be converted. +1 for sure. Those tests would be annotated with @SupressWarnings(“deprecation”) with a comment that they intentionally test the old methods and that the test should be deleted when the old methods are removed.
Re: Discussion on Deprecation
+1 on leaving testing of deprecated functionality in place
On Mon, Mar 16, 2020 at 11:50 AM Dan Smith wrote:
> +1
>
> One point though - we do need to leave some tests that specifically test
> the deprecated method(s), since we still support the deprecated APIs until
> we remove them. Everything else should be converted.
>
> -Dan
>
> On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett wrote:
>
> > Hey Team,
> >
> > When deprecating a symbol, like class or method, please included a
> > reference to the replacement in the java docs. Also please include an
> > example of converting from the old API to the new. I am finding many many
> > places in the source where deprecated code has no hints at all. As many
> of
> > us don’t take the effort to immediately convert old tests over to the new
> > APIs the context is lost when someone finally does get around to it. For
> > public APIs this is extremely important so that users know how to migrate
> > their code with as few roadblocks as possible.
> >
> > Here is an example of something that is much better than most of what I
> am
> > seeing.
> >
> > /**
> > * @deprecated Replaced with something better and safer.
> > * Replaced by {@link Bar}.
> > */
> > @Deprecated
> > class Foo {
> > /**
> >* Do something.
> >*
> >* @deprecated Replaced with something better.
> >* Replaced by {@link Bar#doSomethingBetter()}
> >*/
> > @Deprecated
> > public void doSomething() {}
> >
> > /**
> >* Do something.
> >*
> >* @deprecated Implementation is not safe.
> >* Replaced with {@link Bar#doSomethingBetter()} and {@link
> > Bar#doSomethingElse()}.
> >* Migration example, replace:
> >* {@code
> >* Foo foo = new Foo();
> >* foo.doSomethingAndSomethingElse();
> >* }
> >* with:
> >* {@code
> >* Bar bar = Bar();
> >* bar.doSomethingBetter();
> >* bar.doSomethingElse();
> >* }
> >*/
> > @Deprecated
> > public void doSomethingAndSomethingElse() {}
> > }
> >
> > class Bar {
> > public void doSomethingBetter() {}
> > public void doSomethingElse() {}
> > }
> >
> > -Jake
> >
> >
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
Re: Discussion on Deprecation
+1
One point though - we do need to leave some tests that specifically test
the deprecated method(s), since we still support the deprecated APIs until
we remove them. Everything else should be converted.
-Dan
On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett wrote:
> Hey Team,
>
> When deprecating a symbol, like class or method, please included a
> reference to the replacement in the java docs. Also please include an
> example of converting from the old API to the new. I am finding many many
> places in the source where deprecated code has no hints at all. As many of
> us don’t take the effort to immediately convert old tests over to the new
> APIs the context is lost when someone finally does get around to it. For
> public APIs this is extremely important so that users know how to migrate
> their code with as few roadblocks as possible.
>
> Here is an example of something that is much better than most of what I am
> seeing.
>
> /**
> * @deprecated Replaced with something better and safer.
> * Replaced by {@link Bar}.
> */
> @Deprecated
> class Foo {
> /**
>* Do something.
>*
>* @deprecated Replaced with something better.
>* Replaced by {@link Bar#doSomethingBetter()}
>*/
> @Deprecated
> public void doSomething() {}
>
> /**
>* Do something.
>*
>* @deprecated Implementation is not safe.
>* Replaced with {@link Bar#doSomethingBetter()} and {@link
> Bar#doSomethingElse()}.
>* Migration example, replace:
>* {@code
>* Foo foo = new Foo();
>* foo.doSomethingAndSomethingElse();
>* }
>* with:
>* {@code
>* Bar bar = Bar();
>* bar.doSomethingBetter();
>* bar.doSomethingElse();
>* }
>*/
> @Deprecated
> public void doSomethingAndSomethingElse() {}
> }
>
> class Bar {
> public void doSomethingBetter() {}
> public void doSomethingElse() {}
> }
>
> -Jake
>
>
Re: Discussion on Deprecation
+1
I think we should make it a habit to convert all Geode code as part of the
pull request that introduces the deprecation so that this is not left as a
low priority item for some later point in time.
Something to look for when reviewing pull requests IMO.
On Sun, Mar 15, 2020 at 9:41 PM Jacob Barrett wrote:
> Hey Team,
>
> When deprecating a symbol, like class or method, please included a
> reference to the replacement in the java docs. Also please include an
> example of converting from the old API to the new. I am finding many many
> places in the source where deprecated code has no hints at all. As many of
> us don’t take the effort to immediately convert old tests over to the new
> APIs the context is lost when someone finally does get around to it. For
> public APIs this is extremely important so that users know how to migrate
> their code with as few roadblocks as possible.
>
> Here is an example of something that is much better than most of what I am
> seeing.
>
> /**
> * @deprecated Replaced with something better and safer.
> * Replaced by {@link Bar}.
> */
> @Deprecated
> class Foo {
> /**
>* Do something.
>*
>* @deprecated Replaced with something better.
>* Replaced by {@link Bar#doSomethingBetter()}
>*/
> @Deprecated
> public void doSomething() {}
>
> /**
>* Do something.
>*
>* @deprecated Implementation is not safe.
>* Replaced with {@link Bar#doSomethingBetter()} and {@link
> Bar#doSomethingElse()}.
>* Migration example, replace:
>* {@code
>* Foo foo = new Foo();
>* foo.doSomethingAndSomethingElse();
>* }
>* with:
>* {@code
>* Bar bar = Bar();
>* bar.doSomethingBetter();
>* bar.doSomethingElse();
>* }
>*/
> @Deprecated
> public void doSomethingAndSomethingElse() {}
> }
>
> class Bar {
> public void doSomethingBetter() {}
> public void doSomethingElse() {}
> }
>
> -Jake
>
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
Discussion on Deprecation
Hey Team,
When deprecating a symbol, like class or method, please included a reference to
the replacement in the java docs. Also please include an example of converting
from the old API to the new. I am finding many many places in the source where
deprecated code has no hints at all. As many of us don’t take the effort to
immediately convert old tests over to the new APIs the context is lost when
someone finally does get around to it. For public APIs this is extremely
important so that users know how to migrate their code with as few roadblocks
as possible.
Here is an example of something that is much better than most of what I am
seeing.
/**
* @deprecated Replaced with something better and safer.
* Replaced by {@link Bar}.
*/
@Deprecated
class Foo {
/**
* Do something.
*
* @deprecated Replaced with something better.
* Replaced by {@link Bar#doSomethingBetter()}
*/
@Deprecated
public void doSomething() {}
/**
* Do something.
*
* @deprecated Implementation is not safe.
* Replaced with {@link Bar#doSomethingBetter()} and {@link
Bar#doSomethingElse()}.
* Migration example, replace:
* {@code
* Foo foo = new Foo();
* foo.doSomethingAndSomethingElse();
* }
* with:
* {@code
* Bar bar = Bar();
* bar.doSomethingBetter();
* bar.doSomethingElse();
* }
*/
@Deprecated
public void doSomethingAndSomethingElse() {}
}
class Bar {
public void doSomethingBetter() {}
public void doSomethingElse() {}
}
-Jake
