[squeak-dev] Error in Promises/A+ reject implementation?

Robert Withers robert.withers at pm.me
Thu Jun 4 21:25:12 UTC 2020


Hi Tony,

Well, this Promise implementation made it into the Kernel and schedules 
into the future (this seems to be the only use). So it certainly strikes 
me as official.

Have you ever had a chance to look at the 'CapabilitiesLocal' 
implementation I modeled after ERights, many many years ago? It has 
tests. I would welcome comment & feedback.

Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.

Kindly,
Robert

On 6/4/20 10:16 AM, Tony Garnock-Jones wrote:
> Hi Jakob,
>
> On 4/5/20 12:00 AM, Jakob Reschke wrote:
>> I think our Promise behaves wrong, but I would like a second opinion.
> I think you're right. And I think we should fix it. I'll draft a repair.
>
> I don't think there are many users of Promise out there -- if there are,
> and any are reading this, please speak up if fixing the bug Jakob
> reported would be a problem.
>
>> I think the behavior in our Promise is also in violation with the
>> Promises/A+ specification it claims to implement
>> (https://promisesaplus.com/):
>>
>> [...]
>> 2.2.7 then must return a promise.
>>
>>      promise2 = promise1.then(onFulfilled, onRejected);
>>
>> 2.2.7.1 If either onFulfilled or onRejected returns a value x, run the
>> Promise Resolution Procedure [[Resolve]](promise2, x).
>>
>> 2.2.7.2 If either onFulfilled or onRejected throws an exception e,
>> promise2 must be rejected with e as the reason.
>> [...]
> Thanks for digging into the spec here. That'll be helpful for getting
> the tests right.
>
>> On an only slightly related note, I am unhappy that I cannot debug
>> errors in promise handler blocks [...] Opinions?
> I don't know what to think about this, I'm afraid! I'd be keen to hear
> more from others about what a good alternative to the current behaviour
> might be.
>
> Regards,
>    Tony
>



More information about the Squeak-dev mailing list