Hi all!

Here are related discussions:

Oct 2019: http://forum.world.st/Discussion-Warning-vs-Halt-or-Why-is-a-warning-a-notification-tp5106457.html [http://forum.world.st/Discussion-Warning-vs-Halt-or-Why-is-a-warning-a-notification-tp5106457.html]

Nov 2019: http://forum.world.st/Squeak-s-AssertionFailure-vs-SUnit-s-TestFailure-tp5106818.html [http://forum.world.st/Squeak-s-AssertionFailure-vs-SUnit-s-TestFailure-tp5106818.html]

Apr 2020: http://forum.world.st/Why-is-ModificationForbidden-not-an-Error-tp5114717.html [http://forum.world.st/Why-is-ModificationForbidden-not-an-Error-tp5114717.html]


Best,
Marcel
Am 19.07.2020 00:31:25 schrieb Chris Muller <asqueaker at gmail.com>:
Wow, I actually had to look that up, because I found it incredible, but, lo and behold, there it is, under 5.5.4.5 Message: resume.  Does anyone know why ANSI considers it erroneous?

> Notifications resume by default anyway if not curtailed.

A signaled Notification which is never curtailed is nothing, negative even.  Their value is derived by being handled.  But, if you try to handle a Notification, you're basically forced to resume it if you want to retain the nature as if you didn't handle it.  By not guarantee'ing resumption, ANSI forces handlers and signalers to coordinate when they should be decoupled.

> The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.

Squeak has a couple of places that've been sending #resume from defaultAction since their inception.  My inclination would be to understand what we want to get out of Notification before making any changes.

For me, a Notification is informational output from a program that should always resume afterward and, therefore, whose defaultAction should be to resume: self defaultResumeValue.  Request should be its own major sub branch of Notification for input.


 - Chris


On Sat, Jul 18, 2020 at 7:10 AM Jakob Reschke <forums.jakob at resfarm.de [mailto:forums.jakob at resfarm.de]> wrote:

Chris Muller <asqueaker at gmail.com [mailto:asqueaker at gmail.com]> schrieb am Sa., 18. Juli 2020, 04:42:


As long as Notification>>#defaultAction remains 

    ^nil 

instead of 

      self resume

then Smalltalk>>#run: must handle Notification, otherwise, what Tim said would happen with headless apps, will happen.

resume must not be called from defaultAction according to the ANSI standard. Squeak may differ, but having this in the class library would set a bad example for applications that implement their own notifications. Notifications resume by default anyway if not curtailed. The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/3d254332/attachment.html>