Compiler related PlusTools and ToolBuilder Questions
stéphane ducasse
ducasse at iam.unibe.ch
Sat Nov 5 17:35:58 UTC 2005
>>>
>>> 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.
Ok of course. I was missing the context. Sorry. So this will have to
be fixed.
May be the exception related to the compilation should be part of the
compiler.
I know that SyntaxError inherits from StringHolder :( (so if it would
be regular exception this would be much simpler and
it should be moved to the compiler package).
>>> 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.
yes
I meant critical to know why basicCompile...disappeared since it was
not the source of problem.
More information about the Squeak-dev
mailing list
|