Eelco wrote:
The thing is though, even though it is 100% backwards compatible, it is something we'll have to support. It adds complexity to the implementation, and we'll have to answer questions about it on the list. That would be fine if everyone would have been wildly enthusiastic about it, but that is not the case - whether you think that is justified or not.So, like I propose in the main thread, the best way to go is to implement this as a separate project, using separate tags. We'll be happy to support any internal API changes if that is needed to make the implementation work. The advantage of having this separate project is that such inheritance would be available for people who like it, and hey, maybe in the longer term you have something that works so good that you can convince people based on something that works. Executable code works much better than simply words when it comes to that ;-)
Some small questions on doing this as a separate project:1) If API changes are necessary, is it not adding more complexity that needs to be supported than the change itself? The change is relatively minor change (heck, even mark it experimental/use at own risk/may be removed in a future release). Can the same be said for other API changes yet to be thought of...
2) If other tags are going to have to be used, are tags in the wicket namespace allowed? Would that not be a potential source of future naming conflicts? What is the policy here?
Regards, Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
