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 s
Thanks all. This has gone elsewhere.
Matt
On Mar 19, 2018 8:21 PM, "Matt Sicker" 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,
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 wrote:
> Been out with the flu, jumping in late...
>
> It seems
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 wrote:
> On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
> > On Fri, Mar 16, 2018 at 12:05 AM, Gilles
> > wrote:
> >
> >> Per
On Sun, 18 Mar 2018 13:20:18 +0100, Jochen Wiedmann wrote:
On Fri, Mar 16, 2018 at 12:05 AM, Gilles
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 obvi
On Fri, Mar 16, 2018 at 12:05 AM, Gilles 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
-
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 Mave
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,
On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:
On Thu, Mar 15, 2018 at 4:05 PM, Gilles
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
On Thu, Mar 15, 2018 at 4:05 PM, Gilles 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
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
example
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(THR
12 matches
Mail list logo