HookEmit

[tequdev]

close #365

High Level Overview of Change

Context of Change

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

[RichardAH]

hopefully we'll get this into the release after next

[tequdev]

hopefully we'll get this into the release after next

Due to waiting for the probability of a deterministic build, I don’t add enough tests at this time.

[RichardAH]

I think HookEmit is a bit of a confusing label? Maybe HookEmittable? Or HookCanEmit

[tequdev]

hookSetObj.isFieldPresent(sfHookEmit))

@RichardAH
Yes, at this moment I have chosen HookEmit because of its simplicity and the similarity of its sound to HookOn.
I have no objection to changing the name to something else.

[sublimator]

I think HookEmit is a bit of a confusing label? Maybe HookEmittable? Or HookCanEmit

I agree it's not totally clear even though it is nice and concise.

There's arguments to be made for various names that prioritize brevity, for consistency with existing fields etc, but clarity is important for approachability too. I've chatted to various AIs and they'll be adamant initially that HookEmit is the best, but then can yield to various arguments.

I was drawn to HookCanEmit initially as it's very clear.

What about sfEmitMask ? The hook definition already has sfCreateCode as exception to any perceived Hook* naming convention.

[sublimator]

Maybe a helper function for this