<TimMc>
I just remembered the name, "Waluigi Effect". No idea if it's credible, though.
<isd>
kentonv: I'm trying to suss out some promise resolution stuff for go-capnp. Reading through the docs on disembargos where it talks about the need for promises to forward messages *strictly* to their target, and not shorten multiple hops, it suggests that this isn't an issue because the promise will probably be dropped soon anyway -- so to rephrase, it sounds like this is basically pushing the responsibility for multi-hop shortening to something
<isd>
higher up the chain. What is actually responsible for that? Is the app expected to monitor capabilities for resolution and manually switch over somehow? If not, then how does this work?
<isd>
Oh, just noticed you posted on the issue. I will read that.
<isd>
Good timing
<kentonv>
isd, I think you are overthinking something but I'm not exactly sure what the root of the confusion is
<isd>
In your example, what is P? is it part of the app or part of the library? If the latter, it sounds like it is not allowed to skip over R and send things directly to S.
<isd>
Why can P shorten the second hop, but Q cannot?
<kentonv>
isd, Q exists only to serve P, and it has already told P that P should replace it with R. Q's purpose is now only to facilitate that shortening.
<isd>
In that scenario, has R already resolved to S, or is it still pending, and will eventually resolve to S? If the latter, it seems like the rule says that P has to keep forwarding messages to R, and rely on R to forward them along to S.
<kentonv>
no, it doesn't say that. Once P has replaced Q with R, R is free to tell it to further resolve to S
<isd>
So why can't Q? I don't see what distinguishes P from Q.
<kentonv>
isd, I commented some more on the issue. I think there's confusion about whether we're talking about objects or edges
<isd>
Yeah, I think that's the issue. I'll move the conversation over there so we're not bouncing back and forth.