Product Decisions This Supports
- Scoping numeric-precision requirements for any money-adjacent roadmap item. Billing, invoicing, tax/VAT, currency conversion, interest and fee accrual, refunds, and proration all demand an explicit "how do we represent numbers" decision before estimation. This package is one candidate representation — immutable, self-typed arbitrary-precision value objects instead of raw floats, strings, or loose
bcmath handles — and reviewing it forces that decision into the open rather than letting each squad default to floats.
- Build-vs-buy framing for numeric primitives. It is a useful "buy/inherit the pattern" reference: object API with immutability, fluent arithmetic, no shared mutable state. That said, the archived status (last release 2017-08-31, repository archived, 0 dependents) means the honest conclusion is buy the pattern, not the artifact — standardize on
brick/math or native BCMath/GMP behind an internal interface.
- Risk triage on existing dependency trees. If it already appears in a legacy module, this becomes a bounded remediation item: confirm it is off the critical path, pin the version, and schedule replacement. It is not a feature investment and should not appear on a roadmap as capability work.
- Prioritizing ecosystem bets with real numbers. 129 stars, 0 dependents, and an opportunity score of 23.4 are a quantitative signal of zero community gravity. For roadmap planning, that argues for treating numeric precision as an internal standards decision (contract + adapter + golden tests) rather than an external dependency bet on a frozen repository.
- Domain modeling for high-magnitude values. Crypto/token amounts (wei-scale), telemetry and scientific units, loyalty points, and ID/hash-space arithmetic are cases where 64-bit and float limits become customer-visible product bugs — rounding drift, silent overflow, "off by a cent" reconciliation tickets. This is exactly the class of feature the package targets, even though it is the wrong artifact to depend on.
- Architecture decisions that protect swap cost. Because there is no service provider, facade, or config surface, it is architecturally "invisible" — easy to introduce and equally easy to replace. That invisibility is the main structural argument in its favor and supports a decision to isolate any numeric library behind an application-owned
MoneyCalculator/DecimalMath contract.
When to Consider This Package
Consider it only when:
- You need a read-only design reference for immutable big-number value objects in PHP — API shape, immutability semantics, operator ergonomics — while specifying your own internal numeric types or an adapter over a maintained library.
- You are working in a frozen legacy codebase where the package is already installed, the PHP runtime is pinned, usage is non-critical (reporting, internal tooling, migration scripts), and replacement cost currently exceeds risk.
- You want a timeboxed spike (hours, not days — Composer-only, PSR-4, no migrations) to validate a
Money/Quantity domain model before committing to a maintained dependency.
- You need exact rationals (
BigRational) as a modeling reference for non-decimal proportions, and are willing to treat the source as a spec rather than a runtime dependency.
Look elsewhere when:
- The code is production, customer-facing, or financial. An archived repository with no releases since 2017 means no security response process, no PHP-version compatibility guarantees, and no upstream fixes — unacceptable on money paths. Expect PHP 7.0-era code: no scalar/return types, dynamic properties, implicit-nullable signatures that become deprecations on PHP 8.4 and breakage on future majors.
- You need maintained support and modern PHP compatibility. Prefer
brick/math (actively maintained, arbitrary-precision, immutable value objects) or native ext-bcmath / ext-gmp behind a thin internal wrapper.
- Performance or scale matters: pure-PHP object wrappers add allocation and dispatch overhead versus direct extension calls, and immutability means every operation allocates. Fine for per-request line items, dominant CPU in reconciliation or reporting loops.
- You need decimal semantics (fixed scale, explicit rounding modes, currency-aware behavior) rather than arbitrary-precision integers/rationals — use a decimal/money library instead.
- Eloquent persistence is in scope without bespoke work: there is no first-party cast; you must write one, store values as
string/DECIMAL columns with sufficient scale, and guarantee JSON and queue payloads carry strings, never floats.
- Onboarding and hiring matter: a zero-dependent, archived package with a thin community raises the cost of every future maintainer's context.
How to Pitch It (Stakeholders)
To executives (30 seconds): This is a small, MIT-licensed PHP library for exact big-number arithmetic — the kind of thing that prevents penny-drift, rounding drift, and overflow bugs in pricing, billing, and unit-conversion features. It is not a dependency I recommend adopting: the project is archived, its last release was in 2017, and it has no downstream dependents. The recommendation is to treat it as a design reference and standardize on a maintained alternative (brick/math, or native BCMath/GMP behind an internal wrapper). The recommended path costs about a one-to-two-day spike plus a small recurring maintenance line; adopting an unmaintained numeric library on a money path is a latent correctness and security liability with no vendor to call.
To engineering (why this matters, what to do): The valuable idea here is immutable value objects for numbers — no shared mutable state, no floats in domain code, explicit scale and rounding mode as inputs. We should adopt that pattern, not this artifact. Concretely: (1) audit any existing usage and classify it critical vs. non-critical; (2) for new work, define an internal Money/Quantity abstraction over brick/math or BCMath/GMP, and keep a second adapter behind the same contract for differential testing; (3) keep this repo only as a reference for API ergonomics during the spike; (4) harden the boundaries — custom Eloquent cast, string/DECIMAL columns wider than expected magnitude, serialization tests for JSON and queues, and a rule that values are always constructed from strings and never from floats. Flag the lifecycle risk explicitly: archived upstream, no security patching, unknown compatibility with current PHP versions, pure-PHP fallback that is orders of magnitude slower and may diverge from GMP/BCMath results. No new runtime dependency without a written risk acceptance and a named owner.
Ask: Approve a short (1–2 day) spike to confirm the internal numeric abstraction, its backing library, and the golden test set for rounding, scale, comparison, and overflow; approve deprecation of this package from all new code paths and a scheduled replacement plan for any existing usage.