refactor(store)!: Rename from FarClass to ExoClass, etc

[erights]

Staged on #6107

Addresses endojs/endo#1193 , but more narrowly

@dtribble and I were brainstorming name alternatives to FarClass (which we both hate for somewhat different reasons). There are three salient differences from normal object programming, where FarClass only suggests the first and third.

• It is a remotable, meaning it is exposed to messages from outside the vat (hence "Far")
• Related, it is protected by an interfaceGuard that does the first phase type-like phase of input validation
• It is programmed in a class-like manner, with inline methods in the concise-method syntax, accepting their instance-specific access via their this binding (hence "Class")

We also need to name the instance case, and FarInstance is way too awkward. The instance case has the first two features but not the third.

New aha: "Exo" does double duty.

• As a prefix meaning "outside", it suggests the remotable meaning. That was why I suggested Exo in the first place.
• It lets us introduce the metaphor of the ExoSkeleton without being confused with the exoskeleton itself. "An exo is a creature with an exoskeleton" is a memorable explanation, even if there is no RL noun "Exo".

Also

• It is short, so for the class case "ExoSkeleton" still works.
• It is distinct from our current "Far" and so the "Instance" qualifier isn't needed for the protective instance case.

But this last bullet (distinct from "Far") means that it isn't an answer to our first search for a term, since it doesn't cover remotable objects without a protective exoskeleton (currently, "Far objects" and "remote presences"). Oh well. I think the rename is still worth it.

---

Reviewers, I look forward to your impressions in the review comments.

If this PR meets with your approval soon, we could merge it into #5960 before merging #5960 into master, skipping a phase where we're using the wrong names on master.

[erights]

Reviewers, I look forward to your impressions in the review comments.

If you are not interested in the rename question, please remove yourself from the reviewers list. Thanks.

[erights]

Where I should have started:

The cute thing about the name "Exo" is fitting with the "Endo" brand. This is has both pros and cons. The con is that the name "Endo" gives us a one-time opportunity to use the name "Exo" as a cutely related name. The usage proposed by this PR would use that up. Please consider this as grounds to reject this PR.

Myself, I think whatever term we choose here will rapidly become central to our distributed persistent defensive programming, and so is a good enough pairing with "Endo" to be worth using up the name.

[kriskowal]

Adjacent to the issue at hand, I have an inkling that we’ll someday use “Endonym” and “Exonym” to refer to pet names and edge names in the context of Endo. The words almost line up. We have the option of pairing “Endo” for the daemon/TSR and “Exo” for the windowed application.

[Chris-Hibbert]

I don't mind it. We're going to use this concept often enough that it's valuable to have a short name.

[kriskowal]

I feel that FarClass to ExoClass is a lateral move and I wish I could conscionably ask for more deliberation and more nominations. But, I’m going to do one of those “disagree and commit” things.

If nominations are still open, I would like to suggest “Protocol” instead of “ExoClass”. Protocol emphasizes the role in communication and makes clear that this is the analogue for a Protobuf “service”. The comparison is made stronger with its relationship to schemas. There’s precedent for the term in SmallTalk and [C], as an analogue to an interface. Although we would not be using the term in exactly the same way, I think it’s close enough that it would help communicate the concept more than it would hinder.

[kriskowal]

† [C] is C but with square brackets. That’s to say, Objective-C.

[erights]

If nominations are still open,

Hi @kriskowal , nominations are still open

I would like to suggest “Protocol” instead of “ExoClass”.

There is also the question of naming the objects themselves. For example, vivifyExoClass vs vivifyExo (previously vivifyFarClass vs vivifyFarInstance). If we replace "ExoClass" with "Protocol", what do we call a singleton instance?

In any case, whatever the answers, it's easy to do a global search-and-replace and post the result as a PR such as this. Twas very effective (for me at least) in evaluating Shape->Schema vs Schema->Shape. I like to see what the concrete code looks like. If you did this for Protocol, I'd certainly take a look.

[erights]

To make this exercise more representative of the real question, I rebased it on #6107 , which introduces parallel "Heap" far/exo classes as the in-memory alternative to "Virtual" and "Durable". I also added parallel smoke tests for (Class, ClassKit, Instance) x (Heap, Virtual, Durable, vivify).

@kriskowal , if you do try the Protocol experiment, start from this one.

[erights]

Btw, personally, I find "Protocol" natural to name what "Interface" names --- the API definition, not an implementation of this API. With FarClasses, we're already using the term "InterfaceGuard" to mean the layer than both defines the API and provides the first line of defense for the type-like invariant checking for the interface. Saying a class implements an interface seems natural to me. Saying a protocol implements an interface sounds weird.

Similarly, in our brainstorm @dtribble suggested "Guard" be the name. But to me the guard is guarding something. The thing we're trying to name is the guard together with the actual behavior being guarded. That's why InterfaceGuard seems good.

If Exo too strongly suggested that an Exo is an ExoSkeleton, then it would fail for me on the same grounds. But I think we can explain that an Exo has an ExoSkeleton as a way to make use of the metaphor without falling on the wrong side of the metaphor.

[dtribble]

I was generally more interested in renaming the "vivify" part. In particular:

vivifyFarClass => makeFactory
vivifyFarClassKit => makeFactoryKit
vivifyFarInstance => makeFar

or

makeExoFactory
makeExoFactoryKit
makeExo

I find the term "vivify" to be creepy, and want it to ... not be used :)

[erights]

I'm all for finding an alternative to vivify. But "make" won't do because these are more provide-like than make-like. On revival, your binding behavior to lots of stuff that's already made.

But yes, alternatives to "vivify" are welcome.

"Factory" is not bad. But why do you prefer it to "Class"?

[erights]

Any objections to postponing further renaming until after RC0? I just don't see this closing as quickly as I'd hoped.

[dtribble]

I'm all for finding an alternative to vivify. But "make" won't do because these are more provide-like than make-like. On revival, your binding behavior to lots of stuff that's already made.

It's making the factory function. You didn't have one before and you do as a return result. That happens to take info from the baggage provided, but the factory function is new. Hence make is simple to understand.

But yes, alternatives to "vivify" are welcome.

"Factory" is not bad. But why do you prefer it to "Class"?

Because what you get is a function you call. That's typically called a factory function. It's not a class is most OO languages, including JS (you don't call new on it, don't test types with it, etc.).

[erights]

Good. makeSomethingFactory is plausible.

[turadg]

+1 to deferring to after rc0. Priority-wise, this just isn't an MN-1 concern. But is definitely for MN-2.

When we do work on this, I propose that we have a table of options so we can see how each name idea plays out. I've gathered the ideas in this PR into a public sheet.

Current name	#6118 name	vivify -> make	Protocol 1
vivifyFarInstance	vivifyExo	makeExo
vivifyFarClass	vivifyExoClass	makeExoFactory	vivifyProtocol
vivifyFarClassKit	vivifyExoClassKit	makeExoFactoryKit
makeHeapFarInstance	makeHeapExo
defineHeapFarClass	defineHeapExoClass
defineHeapFarClassKit	defineHeapExoClassKit
defineVirtualFarClass	defineVirtualExoClass
defineVirtualExoClassKit	defineVirtualExoClassKit
defineDurableFarClass	defineDurableExoClass
defineDurableFarClassKit	defineDurableExoClassKit

[turadg]

Since it's easy to reopen a closed PR, I'm closing this one for now so it stops showing up in outstanding reviews.

[erights]

CI doesn't seem to run closed PRs, which is quite sensible. So reopening.

Oops. After force pushing, I do not seem to be able to reopen. Help?

[michaelfig]

Oops. After force pushing, I do not seem to be able to reopen. Help?

I did:

git checkout -b reopen-6118 0a44cfbc 
git push -f origin reopen-6118:markm-rename-to-exo
# reload the Github page
# reopen the commit

[erights]

@michaelfig , thanks for rescuing this PR. However, since I'd already moved the content over to #6323 which is already approved, I'm reclosing this one in favor of that one.