BUG: incompatibility with the interface

[Pavel-NPART]

Computer says no.

Originally posted by @jaapio in #434

So , can you explain why this issue marked as closed without resolve a problem?
You reaction is a worst, and I think that is not good practice to close task without answer to question.

[andrew-demb]

This is not a bug. The previous issue did not contain any questions.

There is no explanation from you as to why you classify it as Critical.

Adding a final mark to the public method of a non-final class COULD be considered a BC break (not a bug). BUT this change is part of a MAJOR version bump, so a BC break could be intended.

If you are pretty sure about the problem, provide a reproducer and explanation, without markers "urgent", "critical", and so on. You can use previous versions of the library if you wish.

[Pavel-NPART]

I think if interface define this method as a "public static" you must accept youself contract in the class implemented this interface.

I added reproduction code here

From one side you take a way to add customer own tags but thru adding "final" to "create" method you:

1. don't respect youself interface
2. blocking customer to adding new customer tag extended TagWithType class (i must changed this into BaseTag)

So, that is the reason in my opinion why it a critical and urgent to resolve

[andrew-demb]

I don't see any reproduction code in the following link

[Pavel-NPART]

[Pavel-NPART]

TagInterface and Helper function are my code

[jaapio]

Hi,

Thanks for reaching out. I think this issue is already way better than your previous issue. From your previous issue, I just got annoyed. Your message was short, non-personal, and didn't explain anything about your use case. I'm glad you felt an equal thing because of my response. Maybe I could have done this in a different way, so did you.

Regarding your problem: v6 contains breaking changes by purpose. The reason we block extending the TagWithType this way is because type definitions in more complex situations cannot be handled by this project. The original code in v5 had limitations.
I agree that this approach is not the nicest way to block this, but at least my message was clear. People from the outside world should not extend this class.
Maybe I should have added an @internal in the docblock of the class. I will do that.

From my point of view, it's a bad practice to extend any class in this project. That's why most classes are final. We provide a BaseTag and an interface to allow you to implement your own tags. But I think you should never extend something you do not own. Extending classes from a project you do not own gives you a very tight binding to the internals of this project. That makes maintenance on your side, but also on my side, much harder. All classes that can be extended by users of this project are automatically part of the public API, which makes it harder to refactor this project without breaking changes. I truly believe that the only reason I could be fully backward compatible for over 5 years was because of the closed architecture of this library.

So your conclusion is right: you have to implement the interface, maybe extend the BaseTag, but not touch the other class.