>> >> >> (Unless, of course you simply raise an error during (re)compilation >> when given ivar removed from class). > That's the plan yes. Niko is working on that part now. I guess for now we > might keep it on Eliot's proposal of just transforming to an undefined field > access; but we'll see. > One of the ideas is of course to collect the methods that get affected by a > change and report back to the user; just like with all other types of errors > that can occur during class modification. We have a pretty cool model already > so it's becoming increasingly easy to install such hooks. I hate self error: > 'your class is invalid because of something somewhere', and we'll get that > all fixed!
I would love to have real object that contains compilation error (instead of Transcript show:) so that we can build tool to fix them :) >> If you create a copy of method, copy the method's trailer. >> >> >> trailer := oldMethod trailer. >> >> newMethod := CompiledMethod newBytes: ... trailerBytes: ***trailer*** >> nArgs: ... nTemps: .. nStack: ... nLits: ... primitive: ... > It seems that the opal compiler has a compiledMethodWith: trailer. Useful ;) > I just had to set the methodClass: and selector: myself. Fair enough. > > @Eliot thanks for the hints. I'll take it into account to make the > recompilation complete. If Niko doesn't finish it this evening I'll probably > do it tomorrow... I'm in the need of a small break :) > > Ignoring the fact that it doesn't support removing instance variables yet, it > would very well already. Pretty cool to see methods updated on bytecode level > without slow recompilation. Aaah... rewriting the classbuilder is starting to > pay off :) And then on to stateful traits. > > Just for credits: I'm working together with Camillo Bruni and Niko Schwarz on > this. > > cheers, > Toon >
