Can you explain your use-case when you need to inherit the ProgressBar? It could help to improve the ProgressBar itself.

the right fix would be to re-bind the closure explicitly to the right class instead. Switching to protected makes the method accessible (and overwritable) in child class, and so impacts the API covered by BC, which is a no-go.

If it doesn't work right now, it won't be a BC break to finalize the class. It just depends on use-cases.

@unkind indeed it is not a bc break, but it will add stuff to maintain because of sf's bc policy which is avoided when possible.

@unkind indeed it is not a bc break, but it will add stuff to maintain because of sf's bc policy which is avoided when possible.

final makes keeping BC easier, what do you mean?

Can you explain your use-case when you need to inherit the ProgressBar?

@unkind I performed some experiments, but my ideas didn't work because of this issue with inheritance. So, at the end I have no real use case, because I went with another approach.

However, my point is: either ProgressBar class must be final or inheritance must be supported, isn't it?

@unkind of course sorry, I didn't understand well what you meant.

I agree with you and I think we should consider make more classes final unless people prove that extending them brings real benefits. Here as this helper is unlikely to be worth being extended, I would be for final.
However, I think it's safer to deprecate extending it for 4.0 (it's really simple) as the error doesn't happen as long as you don't call a method of the helper.

So do I understand correctly that extended the class does only work as long as you do not call the start() method?

@xabbuh yes

In this case declaring the class as final should be valid.

BC Promise disallows to make classes final.
What should I do to make such change in 4.0?

ping @nicolas-grekas, @fabpot
The issue is very simple: ProgressBar is not final, but extending it (even if it is the weird idea) causes Fatal error after calling start().

@a-ast #20493 allows to do this by using the @final annotation.

Does it always throw? This would mean nobody could have extended the class, so making it final would be safe.

@nicolas-grekas yes, it throws always.
It seems that I need to wait until #20493 is merged to continue with my PR, isn't it?

@a-ast I fail to see how #20493 blocks you. As already mentioned, final doesn't break BC anyway in this specific case.

#20493 was only needed in case we considered this change as a bc break. As we don't, you can just directly make the class final.

doesn't break BC anyway in this specific case.

@unkind, @GuilhemN thank you for explanation.
I made the class final and it appeared that some tests failed because they mocked the class to spy on display method.
I've changed the implementation of this tests. Maybe it is not as elegant as before, but, on the other hand, now it is simpler and without mocking.

Thank you @a-ast.