Re: [RFC] Unicode Text Processing

Hi On 12/15/22 19:51, Deleu wrote:

[1] The 'Text' class should likely be made final, because folks might otherwise rely on a specific userland extension, preventing actual interoperability.

I'm fond of final classes but in here I think it *adds* burden to core developers. As you said it yourself having a Type within PHP will help interoperability. Having this type be final will hurt interoperability because everyone's wrapper will be different. This may lead to the community requesting more changes to core.

The wrappers may be different, but they would all be expected to provide a method to retrieve the underlying 'Text' object that every wrapper would know how to use, without the need to actually *convert* between different representations. Furthermore if the class is not final, then every future (method) addition to the class API would be a possible breaking change, if the method is already in use in a userland subclass. For the kind of methods you would add to the 'Text' class there usually is only one reasonable name (there's only so many possible names for "replace", "pad", "split" or similar). Thus any future additions would result in headaches, because (1) either userland breaks, because (2) some less-than-great method name needs to be used or because (3) the addition is not going to happen at all, because (1) or (2) are both unacceptable. Then there's also the point about subclasses not necessarily be a drop-in replacement (either because methods are overriden if not final, or because the immutability is violated). We already had a similar discussion recently with regard to readonly classes, but I'm not sure a gentleman's agreement to not create "incompatible" subclasses is strong enough of a guarantee for something that is a similarly basic build block as the 'string' type itself [1]. Best regards Tim Düsterhus [1] Java's 'String' class is final, I would assume for the same reasons, see also: https://softwareengineering.stackexchange.com/q/97437.