Math Laravel Package

Product Decisions This Supports

• Formula and expression features. The highest-leverage capability behind this package is evaluating math expressions (a Context of variables and functions) — the backbone of configurable pricing rules, discount engines, survey/scoring formulas, quote calculators, commission tiers, and "advanced filter" builders. Whether we build those features, and how, is a real roadmap decision this package informs.
• Build vs. buy on internal math utilities. Arbitrary-precision arithmetic, factorial/combinatorics, and number-theory helpers are the kind of thing teams quietly hand-roll. This package is a useful line item in the "adopt a library / write 200 lines ourselves / use a maintained alternative" comparison.
• Dependency and platform strategy. An archived 2017 library sitting in our composer.json is an input to our PHP version upgrade roadmap (PHP 8.x readiness), our security review process, and our "how many unmaintained vendors do we tolerate" policy.
• Legacy consolidation. If any part of the estate already uses Hoa components, this is the trigger question: do we standardize, fork, or unwind the Hoa stack before the next major release.
• Deliberate non-decisions. Explicitly recording "we will not depend on this" prevents a future engineer from quietly composer require-ing it during a sprint and creating a maintenance obligation nobody owns.

When to Consider This Package

Consider it only when:

• The codebase already depends on Hoa components, and this adds no new vendor risk — the marginal cost of one more Hoa package inside an existing Hoa footprint is near zero.
• The usage is internal-only, non-security-sensitive, and behind a narrow interface (Calculator::evaluate(string $expr, array $vars): float) so it can be swapped later without touching product code.
• You vendor or fork it, pin the version, and have written down who owns the fork and when it gets removed.
• You need math semantics as reference — the grammar/visitor design for expression parsing is genuinely instructive if we're building our own evaluator.

Look elsewhere when:

• You are on PHP 8+. An archived 2017 library should be assumed incompatible until proven otherwise; validating and patching that is unplanned work with zero product value.
• Expressions are user-supplied. Anything that evaluates customer-authored strings is an injection and availability surface; we need an actively maintained, security-responsive parser.
• The feature is customer-facing and long-lived. Pricing, billing, and scoring logic must outlive an abandoned dependency.
• You need precision money math — a maintained arbitrary-precision library is the correct answer, not a general math grab-bag.
• The team has no appetite to review the source. "It has 363 stars" is not a review.

Reasonable maintained substitutes to evaluate instead: symfony/expression-language for safe expression evaluation, brick/math for arbitrary-precision arithmetic (already present in many Laravel dependency trees), and a focused math utility library for combinatorics/statistics. All three carry active maintainers, which is the property we actually need.

How to Pitch It (Stakeholders)

To executives: We evaluated a math utility library as a candidate dependency and are recommending against adopting it. It was archived in 2017, has no active maintainer, and no meaningful downstream adoption. The feature it would accelerate — configurable formulas for pricing and scoring — is deliverable with maintained alternatives at roughly the same engineering effort. The risk is asymmetric: adopting it saves days now and creates a PHP-upgrade and security-review liability that surfaces at the worst possible time, typically during a platform upgrade with a release already committed.

To engineering: Treat this as a reference implementation, not a dependency. Read the expression grammar and visitor pattern if we build an evaluator; ship with symfony/expression-language for user-authored formulas (sandboxed, maintained, Laravel-wrapped options exist) and brick/math for precision. If a legacy service already uses Hoa, isolate it behind a one-method interface, pin the version, and log it in the tech-debt register with an owner and a removal target.

What would change our mind: evidence that we already ship Hoa in production with a funded fork, or a specific math routine we cannot reasonably reimplement and cannot source elsewhere. Absent that, the decision is no — and it's cheap to make now, expensive to reverse later.