Compiler related PlusTools and ToolBuilder Questions
Andreas Raab
andreas.raab at gmx.de
Sat Nov 5 17:24:39 UTC 2005
stéphane ducasse wrote:
> Thanks andreas for the information.
>>> I put back
>>> Parser>>interactive
>>> ^ (requestor == nil or: [requestor isKindOf: SyntaxError]) not
>>> Compiler>>interactive
>>> ^ (requestor == nil or: [requestor isKindOf: SyntaxError]) not
>>> since without them I could not load code because MC was in
>>> interactive mode and I got the error I mentioned in the other thread.
>>
>> This needs to be fixed at some point but I believe it's important
>> that all the other changes are applied *first*. Perhaps this should
>> be delayed to a later update/configuration.
>
>
> I do not get what you want to say exactly.
> Normally all the changes that you packaged have been conflict checked
> by cees and me, and integrated.
>
> So should I interpret that my fixes are ok and putting back the two
> methods described above is ok?
It's okay but *only* for the purpose of making MC happy to load the
latest version of the compiler if that was a problem. It is *not* okay
for Parser and Compiler to refer to SyntaxError because syntax error is
part of the Tools and Parser/Compiler should not directly depend on the
tools.
>> Yes. Because compilation needs to pass along the category as well, so
>> it has been replaced by #compile:classified:notifying:trailer:ifFail:
>> which has the category as an extra argument.
>
> Ok I did not included in the fix since it seemed to me not critical but
> now I scratch the issues from my head.
It *is* critical. This whole set of changes removes the dependency
between Parser, Compiler, and SyntaxError. Before these changes, the
class category of the compiled method was only stored in SyntaxError,
therefore Parser/Compiler could not do proper error handling in the
absence of SyntaxError (since they would not know what the category is).
Having the category in Parser/Compiler fixes these issues, but that's
why the category must be passed along when compiling a method.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|