Hi
On 9/25/26 19:03, Juris Evertovskis wrote:
- Why `final`? Let me add methods while there's nothing in the core.
This is a question that comes up for every new internal (value) class
and has been extensively discussed during the design of ext/uri. To give
a short summary:
- Allowing inheritance allows to break the assumptions of internal
classes, particularly those that store internal state (since you can
just bypass the parent constructor).
- It is impossible to correctly construct child classes, particularly
those that add additional properties, breaking the expectations for
“with-er” style methods.
- Adding additional methods becomes a possible breaking change.
- Liskov Substitution applies not just to the actual API, but also to
the expected behavior. For value classes, the expected contract is “what
the class does”, making it effectively impossible to override anything.
- Why `@not-serializable`? Serialization would seem as straightforward
as for a plain DTO.
- Why not `readonly public` for all params? Inspecting the setup would
be useful to build onto this in userland.
These two are probably a consequence of the initial design of an
“opaque” resource object. I agree that it would be reasonable to lift it
(when a proper API is designed around the proposed class).
Best regards
Tim Düsterhus
