[lang] Todo utility class

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] Todo utility class

Matt Benson-3
I have often thought about creating a utility class that allows me to write
skeletal code that still compiles but will remind me to go back and finish
it. This is a weird meta area of programming, but here are some basic usage
examples:

Foo foo = Todo.todo(); //returns null
Bar bar = Todo.todo(THROWING_EXCEPTION); //throws NotImplementedException
Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and
prints a message to System.err

I would also think it a good (if odd) idea to make the whole class
deprecated so that its use is flagged in tools, etc.

Does the community think this code would be suited to the commons-lang
component?

Matt
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Gilles Sadowski
Hi.

On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:

> I have often thought about creating a utility class that allows me to
> write
> skeletal code that still compiles but will remind me to go back and
> finish
> it. This is a weird meta area of programming, but here are some basic
> usage
> examples:
>
> Foo foo = Todo.todo(); //returns null
> Bar bar = Todo.todo(THROWING_EXCEPTION); //throws
> NotImplementedException
> Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null
> and
> prints a message to System.err
>
> I would also think it a good (if odd) idea to make the whole class
> deprecated so that its use is flagged in tools, etc.
>
> Does the community think this code would be suited to the
> commons-lang
> component?

Perhaps "Commons Testing".
IIUC, such calls are not meant to appear in released code.

Regards,
Gilles

>
> Matt


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Bindul Bhowmik
On Thu, Mar 15, 2018 at 4:05 PM, Gilles <[hidden email]> wrote:

> Hi.
>
> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
>>
>> I have often thought about creating a utility class that allows me to
>> write
>> skeletal code that still compiles but will remind me to go back and finish
>> it. This is a weird meta area of programming, but here are some basic
>> usage
>> examples:
>>
>> Foo foo = Todo.todo(); //returns null
>> Bar bar = Todo.todo(THROWING_EXCEPTION); //throws NotImplementedException
>> Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and
>> prints a message to System.err
>>
>> I would also think it a good (if odd) idea to make the whole class
>> deprecated so that its use is flagged in tools, etc.
>>
>> Does the community think this code would be suited to the commons-lang
>> component?
>
>
> Perhaps "Commons Testing".
> IIUC, such calls are not meant to appear in released code.

I would recommend against commons testing. i would assume that
component would be a dependency with a test scope in most projects,
making it impossible to use it in the main code.

Regards,
Bindul

>
> Regards,
> Gilles
>
>>
>> Matt
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Gilles Sadowski
On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:

> On Thu, Mar 15, 2018 at 4:05 PM, Gilles
> <[hidden email]> wrote:
>> Hi.
>>
>> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
>>>
>>> I have often thought about creating a utility class that allows me
>>> to
>>> write
>>> skeletal code that still compiles but will remind me to go back and
>>> finish
>>> it. This is a weird meta area of programming, but here are some
>>> basic
>>> usage
>>> examples:
>>>
>>> Foo foo = Todo.todo(); //returns null
>>> Bar bar = Todo.todo(THROWING_EXCEPTION); //throws
>>> NotImplementedException
>>> Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null
>>> and
>>> prints a message to System.err
>>>
>>> I would also think it a good (if odd) idea to make the whole class
>>> deprecated so that its use is flagged in tools, etc.
>>>
>>> Does the community think this code would be suited to the
>>> commons-lang
>>> component?
>>
>>
>> Perhaps "Commons Testing".
>> IIUC, such calls are not meant to appear in released code.
>
> I would recommend against commons testing. i would assume that
> component would be a dependency with a test scope in most projects,
> making it impossible to use it in the main code.

That is the feature: when about to release, all "Commons Testing"
modules must be in "test" scope, and if they are used in "main",
compilation will fail.
In development, "main" would depend on "Commons Testing" to allow
usage of "Todo".

Gilles

> Regards,
> Bindul
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Matt Benson-3
I also don't think it belongs in a testing module. OTOH, I appreciate the
desire not to have such hang around in finished code. I think I might
create a dedicated project around this (elsewhere) with a Maven plugin to
provide safeguards around unfinished uses of Todo.

Thanks for considering this,
Matt

On Mar 16, 2018 6:09 AM, "Gilles" <[hidden email]> wrote:

> On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:
>
>> On Thu, Mar 15, 2018 at 4:05 PM, Gilles <[hidden email]>
>> wrote:
>>
>>> Hi.
>>>
>>> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
>>>
>>>>
>>>> I have often thought about creating a utility class that allows me to
>>>> write
>>>> skeletal code that still compiles but will remind me to go back and
>>>> finish
>>>> it. This is a weird meta area of programming, but here are some basic
>>>> usage
>>>> examples:
>>>>
>>>> Foo foo = Todo.todo(); //returns null
>>>> Bar bar = Todo.todo(THROWING_EXCEPTION); //throws
>>>> NotImplementedException
>>>> Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and
>>>> prints a message to System.err
>>>>
>>>> I would also think it a good (if odd) idea to make the whole class
>>>> deprecated so that its use is flagged in tools, etc.
>>>>
>>>> Does the community think this code would be suited to the commons-lang
>>>> component?
>>>>
>>>
>>>
>>> Perhaps "Commons Testing".
>>> IIUC, such calls are not meant to appear in released code.
>>>
>>
>> I would recommend against commons testing. i would assume that
>> component would be a dependency with a test scope in most projects,
>> making it impossible to use it in the main code.
>>
>
> That is the feature: when about to release, all "Commons Testing"
> modules must be in "test" scope, and if they are used in "main",
> compilation will fail.
> In development, "main" would depend on "Commons Testing" to allow
> usage of "Todo".
>
> Gilles
>
> Regards,
>> Bindul
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

AW: [lang] Todo utility class

Jan Matèrne (jhm)
That class is not a regular dependency (test/runtime).
It is more a tool - especially with the mojo you suggested.

So, where we could host tools?

Jan


> -----Ursprüngliche Nachricht-----
> Von: Matt Benson [mailto:[hidden email]]
> Gesendet: Freitag, 16. März 2018 22:22
> An: Commons Developers List
> Betreff: Re: [lang] Todo utility class
>
> I also don't think it belongs in a testing module. OTOH, I appreciate
> the desire not to have such hang around in finished code. I think I
> might create a dedicated project around this (elsewhere) with a Maven
> plugin to provide safeguards around unfinished uses of Todo.
>
> Thanks for considering this,
> Matt
>
> On Mar 16, 2018 6:09 AM, "Gilles" <[hidden email]> wrote:
>
> > On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:
> >
> >> On Thu, Mar 15, 2018 at 4:05 PM, Gilles
> >> <[hidden email]>
> >> wrote:
> >>
> >>> Hi.
> >>>
> >>> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
> >>>
> >>>>
> >>>> I have often thought about creating a utility class that allows me
> >>>> to write skeletal code that still compiles but will remind me to
> go
> >>>> back and finish it. This is a weird meta area of programming, but
> >>>> here are some basic usage
> >>>> examples:
> >>>>
> >>>> Foo foo = Todo.todo(); //returns null Bar bar =
> >>>> Todo.todo(THROWING_EXCEPTION); //throws NotImplementedException
> Baz
> >>>> baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null
> and
> >>>> prints a message to System.err
> >>>>
> >>>> I would also think it a good (if odd) idea to make the whole class
> >>>> deprecated so that its use is flagged in tools, etc.
> >>>>
> >>>> Does the community think this code would be suited to the
> >>>> commons-lang component?
> >>>>
> >>>
> >>>
> >>> Perhaps "Commons Testing".
> >>> IIUC, such calls are not meant to appear in released code.
> >>>
> >>
> >> I would recommend against commons testing. i would assume that
> >> component would be a dependency with a test scope in most projects,
> >> making it impossible to use it in the main code.
> >>
> >
> > That is the feature: when about to release, all "Commons Testing"
> > modules must be in "test" scope, and if they are used in "main",
> > compilation will fail.
> > In development, "main" would depend on "Commons Testing" to allow
> > usage of "Todo".
> >
> > Gilles
> >
> > Regards,
> >> Bindul
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

jochen-2
In reply to this post by Gilles Sadowski
On Fri, Mar 16, 2018 at 12:05 AM, Gilles <[hidden email]> wrote:

> Perhaps "Commons Testing".
> IIUC, such calls are not meant to appear in released code.

Neither would testing. I like the idea of a Todo class. Makes
searching for such places extremely neat, and simple.

Jochen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Gilles Sadowski
On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
> On Fri, Mar 16, 2018 at 12:05 AM, Gilles
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

garydgregory
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 <[hidden email]> wrote:

> On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
> > On Fri, Mar 16, 2018 at 12:05 AM, Gilles
> > <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Matt Sicker
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
> > > On Fri, Mar 16, 2018 at 12:05 AM, Gilles
> > > <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Matt Benson-3
Thanks all. This has gone elsewhere.

Matt

On Mar 19, 2018 8:21 PM, "Matt Sicker" <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
> >
> > > On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
> > > > On Fri, Mar 16, 2018 at 12:05 AM, Gilles
> > > > <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> --
> Matt Sicker <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Todo utility class

Paul King-2
In reply to this post by Matt Sicker
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> > On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
>> > > On Fri, Mar 16, 2018 at 12:05 AM, Gilles
>> > > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
> --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]