- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
partest+ant+reflection and testing is KOed
Mon, 2010-03-08, 17:54
In an unlucky coincidence, I spent the last hour trying to figure out
how the patch I was working on broke partest (since that is indeed what
I'm working on) only to finally have the light go on that maybe it was
some other patch from this morning.
The change to trait naming has shattered partest's ability to
straightforwardly reflect its way to methods, as shown below. The
question I've had for a long time is: is there some good reason
reflection is used so heavily in the partest ant task? If there isn't,
and since I'm working on it anyway, I offer to fix this by simply
ripping out all the reflection, which I'd like to do anyway. It will
take a little while though.
< public boolean showDiff();
< public void showDiff_$eq(boolean);
< public boolean showLog();
< public void showLog_$eq(boolean);
< public boolean failed();
< public void failed_$eq(boolean);
---
> public boolean scala$tools$partest$nest$FileManager$$showDiff();
> public void scala$tools$partest$nest$FileManager$$showDiff_$eq(boolean);
> public boolean scala$tools$partest$nest$FileManager$$showLog();
> public void scala$tools$partest$nest$FileManager$$showLog_$eq(boolean);
> public boolean scala$tools$partest$nest$FileManager$$failed();
> public void scala$tools$partest$nest$FileManager$$failed_$eq(boolean);
Mon, 2010-03-08, 18:47
#2
Re: partest+ant+reflection and testing is KOed
On Mon, Mar 08, 2010 at 06:16:58PM +0100, Philipp Haller wrote:
> I don't see a good reason why reflection is used in the ant task (as
> opposed to the command line runner), since it always uses the class
> loader of the task instance (and therefore its class path) to access
> the runner.
>
> So, I think it can go.
In that case I am on the case.
Mon, 2010-03-08, 18:57
#3
Re: partest+ant+reflection and testing is KOed
Paul Phillips wrote:
> On Mon, Mar 08, 2010 at 06:16:58PM +0100, Philipp Haller wrote:
>> I don't see a good reason why reflection is used in the ant task (as
>> opposed to the command line runner), since it always uses the class
>> loader of the task instance (and therefore its class path) to access
>> the runner.
>>
>> So, I think it can go.
>
> In that case I am on the case.
Thanks! -- Philipp
Mon, 2010-03-08, 19:17
#4
Re: partest+ant+reflection and testing is KOed
Whoa, I was going too fast here. In fact name mangling every field in
a trait is a bit excessive. I just checked in a new ExplicitOuter
which keeps the old behavior except for fields that started out as
private[this] (which still fixes #2946). In a sense I am happy that
ant's reflection discovered this.
Cheers
Mon, 2010-03-08, 19:37
#5
Re: partest+ant+reflection and testing is KOed
On Mon, Mar 08, 2010 at 07:13:53PM +0100, martin odersky wrote:
> Whoa, I was going too fast here. In fact name mangling every field in
> a trait is a bit excessive. I just checked in a new ExplicitOuter
> which keeps the old behavior except for fields that started out as
> private[this] (which still fixes #2946). In a sense I am happy that
> ant's reflection discovered this.
I am happy that you are happy! Still, let's not lose this chance to dump
all that unnecessary and fragile reflection. If you like I can design a
test which will alert us the same way without busting the test suite.
(Actually I should do so even if you don't like, but hey, what's not to
like about a mangling watchdog.)
Paul Phillips wrote:
> In an unlucky coincidence, I spent the last hour trying to figure out
> how the patch I was working on broke partest (since that is indeed what
> I'm working on) only to finally have the light go on that maybe it was
> some other patch from this morning.
>
> The change to trait naming has shattered partest's ability to
> straightforwardly reflect its way to methods, as shown below. The
> question I've had for a long time is: is there some good reason
> reflection is used so heavily in the partest ant task? If there isn't,
> and since I'm working on it anyway, I offer to fix this by simply
> ripping out all the reflection, which I'd like to do anyway. It will
> take a little while though.
I don't see a good reason why reflection is used in the ant task (as
opposed to the command line runner), since it always uses the class
loader of the task instance (and therefore its class path) to access the
runner.
So, I think it can go.
Philipp