Thank you for the feedback, Jakob! I always try to be as specific as possible in the version message, but this one was apparently not precise enough ...


> what is their reason or purpose?


I have been wondering a couple of times when exactly the failBlock passed to a compilation process is evaluated, or rather whether it might be evaluated at all. After analyzing the parser code, I found out that failBlock is evaluated *almost never* provided that the compilation is not interactive, i.e. whenever the specified requestor is nil. I have documented this insight in all relevant public method comments.


> What was that single precedent case?


There was one exception to this (until now) undocumented rule: Parser >> #notify:at: sent an unconditional #fail "for failure setting up syntax error" which appears to be an internal and thus very rare error only. I have added an interactive check at the relevant place to make sure that the following invariant now is always valid:


If the requestor is nil, failBlock will not be evaluated under any circumstances.


This invariant should help us to simplify several users of the compiler API (in the Trunk as well as in external packages) to reduce the number of code branches that need to be honored. For one example of many, in ClosureCompilerTest >> #testDecompiledDoitMethodTempNames, we now know that we don't have to care about the failBlock so the [self error: 'compilation error'] there is officially redundant. And yes, in the future we also might want to introduce a simple #compile:in: convenience method for this purpose. :-)


I hope I could answer your questions ... :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
Gesendet: Samstag, 14. November 2020 16:58:59
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.452.mcz

> Reworks public Compiler interface and documentation:
>
> - Parser: Do not use #fail in the event of an internal error unless compilation is interactive. This was a single precedent case.
> ...
> - Provide new convenience selectors #compileNoPattern: and #compileNoPattern:in: on Compiler instance side.

Independent of whether these changes are good or bad: what is their
reason or purpose? What was that single precedent case? I like to read
such things in the commit message. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201114/735ebbab/attachment.html>