Use symbolic constants in actor export tables

[zgfzgf]

Variables should be used
MethodsAccount.PubkeyAddress instead of 2

specs-actors/actors/builtin/account/account_actor.go

Lines 16 to 21 in 4baf4d4

	func (a Actor) Exports() []interface{} {
	return []interface{}{
	1: a.Constructor,
	2: a.PubkeyAddress,
	}
	}

specs-actors/actors/builtin/methods.go

Lines 13 to 16 in 4baf4d4

	var MethodsAccount = struct {
	Constructor abi.MethodNum
	PubkeyAddress abi.MethodNum
	}{MethodConstructor, 2}

[ZenGround0]

Thanks for filing @zgfzgf. Not sure how I feel about this. On the one hand using the method variables helps us prevent errors. On the other hand seeing the actual number mapping to actor methods has proved to be useful for developing and debugging. But maybe that just belongs somewhere else. What are your thoughts @anorth?

[zgfzgf]

Hi @ZenGround0
Better code readability
It is also easier to find method calls
for example: search in full text with keyword PubkeyAddress

[anorth]

First off @zgfzgf thanks for your contributions. Sorry we've been a bit slow to get to them, but they're much appreciated. Are you on the Filecoin Project Slack? The #fil-actors channel there is good for discussion ahead of changes too.

I'm not in love with how we do these export tables right now, but I don't think #1262 is an improvement. As you noticed, the array literal syntax doesn't permit using vars as the keys, but it has been really useful to have a quick visual look-up between number and method name. Any change we make would have to preserve that somewhere. The current builtin.MethodsXxx tables don't do it.

I haven't had time to consider what a complete do-over would look like, but it would probably change both the per-actor and the tables in builtin. The potential for circular dependency there also adds friction. And since this is a high-touch API for Lotus and other downstream modules, we need to consider the integration path (probably replicating the change on all branches).

[zgfzgf]

It's better to use constant
I also consider relevance, this is a high-touch API for Lotus, So it's modified like this.
now problem for example:
add PubAAA, PubBBB

return []interface{}{
1: a.Constructor,
2: a.PubkeyAddress,
3: PubAAA,
4: PubBBB,
}

var MethodsAccount = struct { 
Constructor   abi.MethodNum 
PubkeyAddress abi.MethodNum 
PubAAA    abi.MethodNum 
PubBBB    abi.MethodNum 

}{MethodConstructor, 2, 3, 4}

later Delete PubAAA
It's not easy to delete. It needs to be mapped

especially:

return []interface{}{
builtin.MethodConstructor: a.Constructor,
2: a.ControlAddresses,
3: a.ChangeWorkerAddress,
4: a.ChangePeerID,
5: a.SubmitWindowedPoSt,
6: a.PreCommitSector,
7: a.ProveCommitSector,
8: a.ExtendSectorExpiration,
9: a.TerminateSectors,
10: a.DeclareFaults,
11: a.DeclareFaultsRecovered,
12: a.OnDeferredCronEvent,
13: a.CheckSectorProven,
14: a.ApplyRewards,
15: a.ReportConsensusFault,
16: a.WithdrawBalance,
17: a.ConfirmSectorProofsValid,
18: a.ChangeMultiaddrs,
19: a.CompactPartitions,
20: a.CompactSectorNumbers,
21: a.ConfirmUpdateWorkerKey,
22: a.RepayDebt,
23: a.ChangeOwnerAddress,
}
@anorth
How to know if there is a mistake in the correspondence?