Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119159
Message-ID: <145c02eb-44f3-e28f-d66b-7e6334539342@bastelstu.be>
Date: Thu, 15 Dec 2022 20:53:25 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Deleu <deleugyn@gmail.com>
Cc: Andreas Heigl <andreas@heigl.org>, PHP internals <internals@lists.php.net>
References: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl>
 <09aa499b-f5ec-5e80-63d8-6271fa87c390@heigl.org>
 <60ba972f-5b7c-f9ea-fb07-7b565bd108cd@bastelstu.be>
 <CADK1yX+btXDOUJ2-43-LX2r0x8kTPp6YTvos9BOmf9D5NZGgng@mail.gmail.com>
In-Reply-To: <CADK1yX+btXDOUJ2-43-LX2r0x8kTPp6YTvos9BOmf9D5NZGgng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Unicode Text Processing
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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.