Deferred from the codebase convergence work. Every fix here renames or reshapes a published symbol of this library, so it is a backward-compatibility break and was deliberately left out of the non-breaking follow-up.
Summary
Boolean properties use two naming schemes, and there is a real argument for each, so this needs a decision rather than a sweep.
Details
| Scheme |
Properties |
| bare, mirroring the config key |
$onFailed, $onEveryStep, $alwaysFullscreen, $purge |
| predicate-prefixed, describing state |
$needsPurging, $scenarioHasScreenshotsTag, $scenarioIsAnimated |
The split is not accidental. The bare names deliberately mirror the behat.yml keys they are populated from, which makes the mapping from config to property obvious. The predicate-prefixed names describe derived runtime state that has no config key.
So the current state may well be correct as-is, with the two schemes marking two genuinely different kinds of property. If that is the intent, it is worth writing down rather than leaving future readers to rediscover it. If it is not, the properties are protected on a non-final class and renaming them breaks subclasses.
Deferred from the codebase convergence work. Every fix here renames or reshapes a published symbol of this library, so it is a backward-compatibility break and was deliberately left out of the non-breaking follow-up.
Summary
Boolean properties use two naming schemes, and there is a real argument for each, so this needs a decision rather than a sweep.
Details
$onFailed,$onEveryStep,$alwaysFullscreen,$purge$needsPurging,$scenarioHasScreenshotsTag,$scenarioIsAnimatedThe split is not accidental. The bare names deliberately mirror the
behat.ymlkeys they are populated from, which makes the mapping from config to property obvious. The predicate-prefixed names describe derived runtime state that has no config key.So the current state may well be correct as-is, with the two schemes marking two genuinely different kinds of property. If that is the intent, it is worth writing down rather than leaving future readers to rediscover it. If it is not, the properties are
protectedon a non-final class and renaming them breaks subclasses.