Enum Catalogs
The package ships with ready-to-use enums for recurring concerns. These are not meant to replace every enum in an application. They exist for cases where the semantics are already broad, stable, and reusable across projects.
Examples by namespace
Calendar:Month,Quarter,Semester,WeekdaySort:SortDirection,NullsPosition,CaseSensitivity,ComparisonResultLogger:LogLevelRuntime:EnvironmentDateTime:IntervalUnitComparison:ComparisonOperatorOutcome:ResultHttp:SchemeProcess:SignalBehavior
What users usually want to know first
Most first-time users ask two questions when they reach the packaged enums:
- "When should I use one of these instead of defining my own enum?"
- "What useful behavior do I get besides the cases themselves?"
The short answer is:
- use a packaged enum when the name and semantics already match your problem
- expect each packaged enum to expose a few focused methods, not just raw cases
Examples with practical behavior
Runtime\\Environment
Use this when your code needs to distinguish between development, testing, staging, and production.
Useful methods:
isProduction()isPreProduction()isDebugFriendly()- inherited helper-style behavior such as
names(),values(), andfromName()
Calendar\\Month
and Calendar\\Quarter
Use these when you want typed calendar logic instead of repeating integer math.
Useful methods:
Month::quarter()Month::isQuarterEnd()Month::ordered()Quarter::months()Quarter::startMonth()Quarter::endMonth()Quarter::includes()Quarter::fromMonth()
Calendar\\Semester
and Calendar\\Weekday
Use these when reports, schedules, or recurring jobs need names that are more explicit than raw integers.
Useful methods:
Semester::months()Semester::includes()Semester::fromMonth()Weekday::isWeekend()Weekday::isWeekday()Weekday::ordered()
DateTime\\IntervalUnit
Use this when you need named interval units for cache policies, schedules, retry logic, or reporting windows.
Useful methods:
shortLabel()seconds()isCalendarAware()
Logger\\LogLevel
and Common\\Severity
Use these when you need reusable severity ordering in logs, alerts, or operational rules.
Useful methods:
weight()isAtLeast()ordered()
Sort\\SortDirection
and friends
Use these when sorting behavior would otherwise rely on magic values or loose booleans.
Useful methods:
SortDirection::reverse()SortDirection::applyToComparisonResult()NullsPosition::compareNullability()CaseSensitivity::normalize()CaseSensitivity::equals()ComparisonResult::fromComparisonResult()ComparisonResult::toComparisonResult()
Comparison\\ComparisonOperator
Use this when building filters, query abstractions, or rule systems that need typed operators.
Useful methods:
symbol()isSetOperator()compare()negate()
Common\\Priority
Use this when work queues, support tickets, alerts, or retry policies need a small reusable priority vocabulary.
Useful methods:
weight()isHigherThan()isLowerThan()ordered()
Http\\Scheme
Use this when URLs or transport policies should distinguish http
and
https
without string checks.
Useful methods:
isSecure()- inherited enum helper behavior such as
values()andfromName()
Process\\SignalBehavior
Use this when process runners or worker loops need to describe what should happen after a signal.
Useful methods:
isTerminalControl()
Event\\DispatchMode
Use this when an event dispatcher, message bridge, or outbox integration needs to carry whether work is expected to happen now or later.
Useful methods:
isSync()isAsync()
Container\\ServiceLifetime
Use this when a container adapter needs a small non-PSR-specific vocabulary for singleton and transient services.
Useful methods:
isReusable()
Pipeline\\FailureMode
Use this when pipeline or middleware execution needs to state whether a failure stops the chain or is collected while execution continues.
Useful methods:
stopsOnFailure()
Outcome\\Result
Use this when your code needs a compact success/partial/failure outcome type.
Useful methods:
isSuccessful()isCompleteSuccess()isFailure()
How to evaluate a packaged enum
A packaged enum is usually a good fit when:
- the case names already match the language you would naturally use
- the behavior would look strange if you had to rename every case
- the enum would make sense in more than one package or application
A packaged enum is usually a poor fit when:
- your business vocabulary differs from the generic names
- labels need to be heavily customized
- the lifecycle or transitions are domain-specific
New-user guidance
Use the packaged enums when the semantics are already general and stable.
Prefer defining your own enum when:
- the cases are domain-specific
- the labels are business-language driven
- the lifecycle or behavior only makes sense inside one package
Examples of strong fits
Runtime\\Environmentfor deployment/runtime distinctionsCalendar\\MonthandCalendar\\Quarterfor date-related calculationsSort\\SortDirectionandSort\\NullsPositionfor ordering behaviorLogger\\LogLevelfor reusable severity-style decisions