> In conclusion, the proposed change: > - is useful > - does not have to be used if you don't like it > - is 100% backwards compatible > - it introduces no new tags (if using child/extends)
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 ;-) Do people want to work on this? Regards, Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
