Re: [RFC] Duration class

Hi On 2026-07-01 20:18, Larry Garfield wrote:

We will thus keep instance methods for “addition” and “subtraction”. If someone has a suggestion regarding naming (particularly with regard to negate() vs negated() and multiplyBy() and multipliedBy()), I'll be happy to discuss that. Java uses plus, minus, multipliedBy, dividedBy and negated. Golang is just using an integer (meaning you just use the operators). Rust’s std::time::Duration uses add, sub, mul, div (with saturating and checked variants), but also overloads operators. Rust’s chrono::TimeDelta is similar to std::time::Duration, but doesn't have the saturating variants. JavaScript’s Temporal uses add, sub, negated and doesn't support multiplication and division. Please keep the divide**By**() (Duration / int -> Duration) vs divide**Into**() (Duration / Duration -> (int, Duration)) suggestion in mind when having opinions about the naming. See: https://news-web.php.net/php.internals/131634

negated() would be consistent with the "ed means return new" pattern found in many languages, so I would strongly recommend following that pattern.

Yes. The only issue I'm having with that is that it doesn't trivially transfer to addition and subtraction, which technically would be an inconsistency in the API. Maybe that's okay, particularly given that both Java and JavaScript have the -ed for everything exception addition and subtraction, but I nevertheless want to have the discussion.

For the others, my inclination is to go short (add, sub) for easier typing and a more compact result, but that's not a make-or-break issue for me.

Having slept over it, I would prefer the full subtract(): Our naming policy mentions to that “Abbreviations and acronyms as well as initialisms SHOULD be avoided wherever possible” (https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#acronyms). ------------ To further complicate matters, the relatively new BcMath\Number class goes with add, sub, mul, div. Given that we need two division operations here, we’ll need the suffix and divBy and divInto don‘t really roll off the tongue well, particularly the latter :-| Best regards Tim Düsterhus