Le 27/04/2021 à 18:46, David Gebler a écrit :
What's being proposed in the RFC is a functional change to the language whereby attempting to extend a class designated as sealed to a non-specified child results in a fatal error.
It's not a functional change to the language, well, it is a new feature, but it's actually not changing any paradigm in the language or the engine. People will continue to write the same code, and people that want to use it for some library or customer project internal purpose may use it.
Now that is not a benefit in itself, it is merely a description of the proposed change. My question is who or what benefits from this change? And I look at this way: 1. The language engine doesn't benefit, since unlike some compiled languages, there is no indication here it will result in improved opcode sequences. 2. The author of code doesn't benefit, to any extent greater than they would by using an attribute or other metadata to indicate their intentions, because if someone else comes along, installs their library and creates problems for themselves by extending some concrete type in a manner which was not intended, the author's obligation to them is zero. If improperly inheriting or otherwise misusing code creates a problem for a consumer, it's the consumer's mess to sort out.
I think that the debate "but if your seal your classes I won't be to extend it" is overrated: it's not the language to chose whether or not the library/software author can seal its classes or not, it's up the library/software author to do its own choice. And in that regard, having "sealed" classes in the language is actually bringing that possibility to the library author, so it's more liberty.
By design, by convention, in any of a company or an open source software community, it can be legit to explicitly hard-seal stuff, for blocking users when they are doing it wrong, if for example by attempting to inherit they will break other existing piece code, for example. There's many scenarios where it's legit to seal classes, and it can be a good practice also (depend on your practices I guess).
But if sealing means "you who want to change a behavior, you need to fix other things deep in the code before being able to do that" then it's good (and it's one of the use cases of sealing).
So each time someone use the "but we won't be able to legitimately extend your class" he's basically saying that people that do put very thorough and strict conventions in their own code are wrong by nature and don't understand what is good. It's almost an insult - please don't misunderstand what I say, I don't think at any moment that any of the people here really meant that, but it it's fundamentally what this argument does: it says that some conventions are by nature bad and the language should enforce people not to write code like this.
I think the language should not enforce any practice, convention or code style, it must remain neutral considering people's whereabouts, workflows or practices. If one's want to seal his or her class, let him or her do it.
I think this point/argument should be banned from this discussion. Sealed classes are good under some conditions, maybe bad under others, that's not the point, it's not about discussing each developer's, community's or company's own conventions, but about is it OK technically to add this feature to the language, and will it be or not a maintenance burden, and finally will it actually break millions of lines of existing code.
I'm inclined to say yes, it is good to add this feature, and I'm skeptical about the fact that it would break existing code (except for people that named their classes "Permits"), there's many use cases I wish I had it in the past. I can live with it, but sometime, it could be the right tool.
Regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
