2011/3/28 Stéphane Ducasse <[email protected]>: >>> >>> >>> (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
