2011/3/28 Stéphane Ducasse <stephane.ducasse@inria.fr>:
(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 :)
Various errors can occur at different stages, hence be generated from different classes in current (old) Compiler: - errors at parsing (syntax errors) - errors at name resolving (shadowing, undeclared ...) - errors at code generation (byte code limits ...) Several alternatives APi are possible for handling these errors: - Compiler signal all warning/errors by raising Exceptions, Compiler invocations are wrapped with a handler - Compiler signal all warnings/errors by sending a message to a reified errorHandler inst. var. The errorHandler can be instanciated with different classes for interactive / non interactive The errorHandler knows itself how to interact with user thru TextEditor, menus, or transcript... There is already a mixture of these strategies in current (old) Compiler. Except that compiler talks directly to a requestor and tries to handle interaction by itself if interactive. IMHO, it's better to write all your requirements before thinking of an architecture. Nicolas