On 31.03.19 00:57, Paul King wrote:
The other "interim" fix would be to try to have more AST xforms run
before stub generation. This would not be about trying to do stub
generation later but running (some) xforms during a first phase and then
rolling back phases and proceeding normally. This isn't a general
solution but could cover some more cases.

My feeling is that this is going to be messy and error prone


We would perhaps mark xforms
with a marker interface if they were amenable to such processing, e.g.
if they are idempotent by nature or can be made so by storing some state
in node metadata to indicate they have already been run. We also need to
look at which bits of the current compiler could be run during that
first phase and then pick xforms that are compatible with this
(potentially) limited processing. We'd obviously not want to make the
compiler significantly slower nor break existing xforms, nor make IDE
support significantly harder, so I imagine there would be just some
specific cases that we would try to support and numerous limitations.

that's what we did in the past for the most part. Maybe some xforms
could be split into an early and late step.. but something almost
essential we cannot do really.. run class resolving multiple times.
Because it is too slow - afaik

bye Jochen

Reply via email to