Consider renaming Promise class

[jamessimone]

Hey there, thought I'd drop a line - which is not meant to be a poke in the eye - concerning the Promise class. It feels misleading, and particularly if I was coming to Apex from JavaScript and saw this framework, I wouldn't know what to make of it.

From MDN's first line of documentation (emphasis mine):

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

This is fundamentally at odds with what a Queueable - or any asynchronous method in Apex, regardless of the underlying implementation - can actually provide to a synchronous caller. For better or for worse, the only "resulting value" we can expect is an AsyncApexJob Id, or a string passing a message. I'm curious on your thoughts about this, since the actual behavior (beyond success/error handling) is really more akin to eventing (fire and forget) than it is to something that's awaitable.

[codefriar]

@jamessimone

First, thank you for taking the time to comment. It's an honor to get feedback from you. I don't want to be ignore your feedback, but I do feel obliged to insert the required 'naming things is hard' joke ;)

I'm all for renaming this. I have two follow up questions I'd love your feedback on.

1. Do you feel like Apex is capable of having a Promise structure similar enough to Javascript to be called Promise? Is this a Naming bug, or an engineering failure? I suspect we're talking about a naming bug? But I'd love your thoughts?
2. As I understand things, this isn't a Promise, but it is Promise-like-thing built via tail-recursion, in that you can queue asynchronous work item(s) with the promise of an eventual answer. It's not truly await-able because the eventual completion is in a different transaction. Is your concern that lack of same-transaction-ness?

All that said, I'm not sure what a better name might be? Have you any suggestions? @dschach how about you?

[jamessimone]

Hey, no worries. Life gets busy. To (attempt to) answer your questions:

1. at present, there’s nothing like a Promise in Apex. The whole identity of a Promise is tied up in the concept of a value being resolvable; for better or for worse, we don’t have that
2. My concern is indeed that complete lack of same transaction-ness in the eventual response

Stacks and queues are both great examples of abstract naming because they evoke exactly what you’re dealing with visually. The event bus, as well, does a great job (in my opinion) of communicating the fundamental disconnect between firing an event and how you eventually deal with a “response.” All of that is to say — I don’t want to impose a name offhand. My concern is more for people whose introduction to Apex might be through ApexKit, and in trying to find a concept that eases them into it without reusing a name for a different async concept.

[dschach]

Hi - wow, time flies, and I just realized I forgot to respond to this discussion. I have listened to Kevin's podcast with Josh Birk (funny how he's the connector for all my Apex learning and favorite people lately) and I'm in agreement that Promise may not be the best word, but I really love the concept of what Kevin is creating here... although I don't have a better name. If Salesforce can invent "Quiddity," perhaps we can come up with another Harry Potter-esque name.

This sounds like a financial instrument where I'm guaranteed to get something back. Perhaps Dividend? Distribution (NO)? Disbursement?

Go for it, @jamessimone - suggest a name. It won't be imposing.

[jamessimone]

@dschach I'm pretty boring when it comes to naming, in the sense that I will always prefer description over evocation (sorry Quiddity, you probably wouldn't have passed muster if I'd seen the PR 😅). To me, this is a QueueableChainer (or perhaps even QueueableCollection). The onus is still on the consumer to start it up; the fact that that responsibility is then shared with Chain suggests that the two should be consolidated (just one person's opinion, and certainly I'm a fan of private internal classes, but there it is). It's still not ideal, but it is descriptive.

On the subject of getting something back - at first, I was tempted to agree, but when I re-examined the existing Promise implementation, it's really just encapsulating a collection of queueables. It would be one thing if the System.enqueueJob call were a part of this facade , but since it's still up to the consumer to start the whole thing, it doesn't actually seem it's a guaranteed investment at all.