[squeak-dev] The Inbox: KernelTests-jr.383.mcz
asqueaker at gmail.com
Thu Jun 25 00:54:24 UTC 2020
Unrelated to your concern about Notifications, I notice the test assigns p
to the result of sending #value to the Promise, which will very possibly
still be nil at that point, even though it then goes on to test it against
#isResolved and #isRejected right afterward.
I find the impedance mismatch between values and Promises of values
confusing, too, -- afterall, I thought the purpose was to be able to use
them interchangeably. Equally, I wish 'error' were always some kind of
Exception, and would signal it when #value (wait) was sent instead of
exposing Promises by forcing clients to ask, #isRejected? #isResolved?
On Sun, Jun 21, 2020 at 12:46 PM Jakob Reschke <forums.jakob at resfarm.de>
> I am trying to come up with a nice solution for this failing test.
> Am So., 21. Juni 2020 um 19:27 Uhr schrieb <commits at source.squeak.org>:
> > A new version of KernelTests was added to project The Inbox:
> > http://source.squeak.org/inbox/KernelTests-jr.383.mcz
> > ==================== Summary ====================
> > Name: KernelTests-jr.383
> > Author: jr
> > Time: 21 June 2020, 7:27:47.560506 pm
> > UUID: ecddb3cb-25c9-6c43-a879-59e527a3a9ee
> > Ancestors: KernelTests-tonyg.382
> > Test whether Notifications reject the promises of future sends
> > In my opinion, they should not.
> > =============== Diff against KernelTests-tonyg.382 ===============
> > Item was added:
> > + ----- Method: PromiseTest>>testFutureResolutionWithNotification (in
> category 'tests - future') -----
> > + testFutureResolutionWithNotification
> > + | p |
> > + p := [Notification signal: 'should not reject'. 3 + 4] future
> > + self assert: (self waitUntil: [p isResolved or: [p isRejected]]
> orCycleCount: 100).
> > + self assert: p isResolved.
> > + self assert: 7 equals: p value.!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev