Re: [MO-java-dev] InterfaceImplementor

[Jeff M. <je...@mk...>]

I find !!javap path.to.Interface works fairly, and I bet if I wasn't so
lazy I could write a vim macro to do the rest. Someones implemented
tetris in vim so I should be able do do that. Try that in IDEA ;-P

!!javap path.to.Interface
:1,$s/abstract //
:1,$s/;/{^M^I^InotImplemented();^M}

That would probably do it.

On Wed, 2002-04-17 at 22:21, Steve Freeman wrote:
> For those of us (unlike Jeff) using an IDE, aligning class with
> interfaces is pretty easy.
> 
> What I find more interesting is the idea of using dynamic proxies to
> catch the unimplemented methods (like Smalltalk doesNotUnderstand),
> rather than the EasyMock approach of using a dynamic proxy to record and
> playback the behaviour. You could then use local overrides to implement
> the behaviour for a given test. Now Jeff has split the jdk's it might be
> worth investigating this for versions 1.3+
> 
> Steve
> 
> ----- Original Message -----
> From: "Jeff Martin" <je...@mk...>
> To: "MockObjects" <moc...@li...>
> Sent: Wednesday, April 17, 2002 1:53 PM
> Subject: Re: [MO-java-dev] InterfaceImplementor
> 
> 
> > My problem is with the autogeneration, but with what is being
> generated.
> > I'm not happy with having the stub classes which are gradually
> > superseded, I think it could leave us with lots of classes which
> > eventually serve no useful purpose.
> >
> > As a starting point for new mocks I don't have a problem with
> generating
> > the code, but creating stubs for everything is not something I'm happy
> > with.
> >
> > But of course that's just my opinion, others may feel differently ;o)
> >
> > On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> > > On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > > > Thanks for this, but I'm not sure it's really the approach we want
> to be
> > > > taking. I'd prefer to keep things a bit cleaner even if that means
> > > > having lots of methods with just notImplemented(); in them.
> > >
> > > I have to disagree - I don't think that's the clean approach. I
> don't like the
> > > idea of humans creating anything repetitive, anything that a
> computer could
> > > create. There's more possibility for error that way. Or even
> copying/pasting
> > > repetitive, automatically generated code. That code just serves to
> obscure
> > > where the real work is being done.
> > >
> > > > You might be interested in
> > > > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes
> your
> > > > approach a bit further.
> > > >
> > > > There is also some work being done on use java.lang.reflect.Proxy
> to
> > > > provide a default mock implementation. But I'm not aware of the
> details
> > > > of this yet.
> > >
> > > Those are both interesting. I'll look more at them.
> 
> 
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
--