Synthetic methods in compiler plugins - a way forwards?

[Paul Butcher]

I've just been looking at writing a compiler plugin to generate typesafe mock objects, and I fear that I'm about to run straight into the same kinds of problems that Kevin's hit with the autoproxy plugin (i.e. of having to run both before and after the typer).

It did occur to me that I could, instead, write a little utility that uses reflection to generate source code, but I fear that that's a non-starter because it's going to fall foul of type erasure.

But - is there any reason why I shouldn't write a compiler plugin that generates source code? I could have it run after the typer (so it has access to all the type information it needs) and before type erasure. Normally it would do nothing, but if switched on with a custom compiler option, it would write source code that could then be used in subsequent compilations?

Is there any reason why this is a really bad idea?

Alternatively, is there anything that's changed recently that means that generating synthetic methods in a plugin is likely to work better than it has in the past?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: pa...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

[Kevin Wright]

I'm working on scalac support for plugin method synthesis at the moment.

As it stands, there's a lot of extra stuff that went into scalac for the presentation compiler that helps with many of the issues caused by my original approach (e.g. run namer and typer twice, doing synthesis between the two runs).

In the end though, I decided to change tactic and directly modify the compiler to support this.  I can't, with clean conscience, continue down a path that's guaranteed to make the compiler any slower.  I just wish I could give some idea as to when I'll have something to show for my efforts :)

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Miguel Garcia]

"Paul Butcher" <pa...@paulbutcher.com> wrote in
message news:C80864A1-6BCE-4600...@paulbutcher.com...

> it would write source code that could then be used in subsequent
> compilations?
> Is there any reason why this is a really bad idea?

Not sure whether it's the best approach for the case at hand, but emitting
modified sources has proved quite useful in at least one scenario: a batch
tool to migrate sources into a new API:
http://lamp.epfl.ch/~magarcia/jdk2ikvm/

Miguel
http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/

[Paul Butcher]

On 24 May 2011, at 18:08, Miguel Garcia wrote:
> Not sure whether it's the best approach for the case at hand, but emitting modified sources has proved quite useful in at least one scenario: a batch tool to migrate sources into a new API: http://lamp.epfl.ch/~magarcia/jdk2ikvm/

Great - thanks for the pointer!