Am 19. Juni 2026 18:35:03 MESZ schrieb Larry Garfield <[email protected]>:
>On Fri, Jun 19, 2026, at 11:26 AM, Marc B. wrote:
>
>> Thanks for being this up. I think that's a sensible approach and can be
>> used as a starting point for further improvements to the date/time API.
>>
>> Some comments though:
>
>> 4. You have some operator methods defined (+add, -sum, /multiplyBy,
>> <>=compare, what about other operators?
>
>What would those be? Personally I'd want to see operators for add and sub, at
>least, but I'm not sure what else would be useful.
Omg, I wrote in a wrong way - sorry.
I mean the RFC just mentions "The Time\Duration class will also implement
internal “comparison handlers”, which means that direct comparisons with
operators such as < will work".
So there are no other operators defined but there are methods defined for it. I
would expect these defined as operators as well.
Actually, for the division, there are two use cases but the method supports
only one.
6s / 2 = 3s
6s / 2s = 3
>
>> 5. Did you thought of supporting float on the initializer methods?
>
>Floats introduce all the complexity and lack of precision of, well, floats.
>Best to avoid them.
If you have a float at hand you already have the lack of precision. Forcing the
user to cast to int before does not make anything better. It's even another
source of complexity the user have to deal with. If this gets handled on the
initializer it will reduce the complexity for the user.
>
>> 6. You should at least mention that this class works with a fixed
>> definition of e.g. how long a minute is - no leaps tz handling here.
>> Which is the correct approach for it.
>>
>> 7. Naming consistency ... add/sub vs. multiplyBy. Why not
>> addBy/sub[tract]By or multiply to be more consistent?
>
>I concur here.
>
>> 8. negative vs. isNegative
>>
>> 9. negate() I would expect to get back a negative Duration. Also, it
>> sounds like modifying the duration but I'm assuming a new instance gets
>> returned. What about inverted()?
>
>Good point. negated() would be fine, I think. (As noted elsewhere, sort() vs
>sorted() is a very common pattern for "modify in place" vs. "make new", across
>a number of languages.)
>
>--Larry Garfield
