Groovy has some features which might give you some ideas. Firstly, it let's you easily create dynamic objects in numerous ways. Typically you might use a Closure or map of Closures. You can optionally specify one or more interfaces and if needed give a base class. You could no doubt do something similar using lambdas in Java.
It also has an @AutoImplement annotation which you can place on any class to get dummy implementations for any abstract methods. By default you get empty implementations (returning default values if needed, e.g. false, 0, null) or you specify an exception to throw. For testing, it also has a @NotYetImplemented annotation and a GroovyAssert.notYetImplemented() method. Both flip the result of JUnit tests. That way you can specify what the behavior of your TODO object is supposed to do and it won't break your test suite. Cheers, Paul. On Tue, Mar 20, 2018 at 11:21 AM, Matt Sicker <boa...@gmail.com> wrote: > I’ve used NotImplementedException as a way to do this. In Scala, there is a > function called ??? which throws a similar exception, and in Kotlin, > there’s an equivalent function called TODO. > > On Mon, Mar 19, 2018 at 20:09, Gary Gregory <garydgreg...@gmail.com> wrote: > >> Been out with the flu, jumping in late... >> >> It seems like using one or more annotations would be better for tooling... >> >> Gary >> >> On Sun, Mar 18, 2018, 07:57 Gilles <gil...@harfang.homelinux.org> wrote: >> >> > On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote: >> > > On Fri, Mar 16, 2018 at 12:05 AM, Gilles >> > > <gil...@harfang.homelinux.org> wrote: >> > > >> > >> Perhaps "Commons Testing". >> > >> IIUC, such calls are not meant to appear in released code. >> > > >> > > Neither would testing. >> > >> > Exactly, and the reason why I proposed that home. >> > Rationale is pretty obvious IMHO: code that contains calls >> > to a "Todo" class is under test (or in beta state). >> > >> > Gilles >> > >> > > I like the idea of a Todo class. Makes >> > > searching for such places extremely neat, and simple. >> > > >> > > Jochen >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
